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ABSTRACT 


In  this  thesis,  we  address  the  problem  of  constructing  multictist  data  distribution 
trees  with  guaranteed  quality  of  service  (QoS)  for  supporting  multiparty  interactions. 
We  present  an  approach  that  integrates  reservation  with  tree  construction  to  facil¬ 
itate  a  guaranteed  quality  of  service.  The  proposed  approach  is  based  on  the  use 
of  information  about  participants  registered  before  the  interaction  starts.  We  first 
identify  the  design  goals  for  multicast  tree  construction  with  minimum  QoS  require¬ 
ments.  We  then  describe  a  protocol  to  locate  a  set  of  distribution  centers  for  an 
interaction  that  depends  upon  the  current  load  distribution,  locations  of  the  par- 
ticipajits,  and  their  QoS  requirements.  The  protocol  sets  up  a  suitable  number  of 
center-specific  trees  for  the  interaction  transparently.  We  compare  the  quality  of 
the  resulting  trees  on  large,  hypothetical  networks  with  that  of  sender- specific  and 
Steiner  trees.  Our  results  show  that  center-specific  trees,  built  around  the  centers 
located  by  our  approach,  reserve  fewer  resources  than  sender-specific  trees  even  for  a 
significant  number  of  simultaneous  senders  while  sacrificing  minimally  in  the  average 
delay  faced  by  each  receiver. 
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I.  Introduction 


The  integrated  packet  switched  networks  of  the  future  are  expected  to  provide 
users  with  the  ability  to  engage  in  various  types  of  multiparty  interactions.  Some 
examples  of  these  are  teleconferencing,  virtual  classroom,  remote  panel  discussion, 
remote  telemetry  and  reconnaissance,  distributed  simulation/test  environment,  and 
virtual  cafe.  All  these  interactions  benefit  from  a  network-level  multicast  with  a 
guaranteed  Quality  of  Service  (QoS). 

Network-level  multicasting  refers  to  reduction  in  the  amount  of  traffic  in  the  net¬ 
work  for  implementing  point-to-multipoint  communication  when  compared  to  mul¬ 
tiple  unicasts.  Wherever  the  associated  unicasts  share  a  path,  a  single  packet  is 
sent.  Where  the  paths  of  the  unicast  diverge,  duplicates  of  the  packet  are  created 
and  routed  down  each  of  the  ensuing  paths.  The  multicast  packet  is  addressed  to  a 
group  address  instead  of  an  individual  address.  This  requires  the  network  to  know 
the  members  of  the  group  and  their  location.  In  order  to  prevent  the  inefficiency 
resulting  from  a  broadcast  that  would  flood  the  network  to  get  to  destinations  that 
correspond  to  members,  a  multicast  tree  is  formed.  This  tree  directs  the  packets 
toward  the  members  and  avoids  routing  the  packet  along  any  path  that  does  not 
lead  to  a  member  of  the  group.  Use  of  some  such  technique  for  tree-construction 
is  essential  if  the  efficiency  gained  in  multicasting  is  not  to  be  counteracted  by  the 
waste  of  resources  in  a  broadcast.  [Ref.  1] 

Current  network-level  multicast  techniques  are  aimed  at  providing  a  best-effort 
delivery,  on  lines  similar  to  the  UDP  datagram  delivery.  In  the  presence  of  congestion 
(lack  of  resources)  and/or  failures,  packets  may  not  be  delivered.  A  multicast  with  a 
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guaranteed  QoS  refers  to  provision  of  guarantees  at  least  as  far  as  the  availability  of 
network  resources  required  for  delivery  of  multicast  packets  is  concerned. 

There  are  two  major  approaches  to  multicast  tree  construction:  center-specific 
trees  (CST)  ^  [Ref.  2]  and  sender-specific  trees  (SST)  [Ref.  3,  4].  \  single  tree, 
rooted  at  some  center  (router)  is  shared  by  all  senders  to  a  group  in  the  former 
approach,  while  each  sender  builds  a  separate  tree  rooted  at  itself  in  the  latter.  The 
advantages  of  a  CST  are  that  network  routers  must  maintain  interface  state  only 
for  a  single  tree  per  group  regardless  of  the  number  of  senders  to  it,  and  in  case  of 
multiple  simultaneous  senders  requiring  reservations,  the  total  amount  of  resources  is 
less  than  SSTs.  The  drawbacks  of  a  CST,  as  proposed  in  [Ref.  2],  are  that,  for  large 
and/or  widely  spread  groups,  certain  backbone  links  may  become  a  bottleneck,  and 
in  case  of  groups  with  all  members  being  senders  requiring  QoS,  network  resources 
may  be  utilized  non-uniformly  resulting  in  traffic- concentration  [Ref.  5).  Another 
drawback  of  this  technique  is  that,  in  the  existing  literature,  there  is  no  proposal  for 
quickly  locating  a  core  to  build  a  CST  from.  The  center-specific  tree  construction 
approaches  have  proposed  that  the  centers  be  selected  administratively.  This  is  likely 
to  prevent  congestion  of  traffic  in  the  network  by  locating  the  center  based  on  the 
group  members’  locations.  * 

The  advantages  of  source- specific  trees  £ire  that  it  is  scalable  and  efficient  in 
case  of  a  large  number  of  simultaneous  senders  (even  if  they  require  guaranteed 
QoS).  The  volume  of  traffic  carried  by  each  tree  remains  the  same  regardless  of  the 
number  of  senders.  It  is  also  argued  that  the  source-specific  approach  permits  the 
highly  desirable  flexibility  in  providing  receiver-initiated  reservation  to  guarantee  QoS 

^We  avoid  the  ose  of  center-based  trees  to  prevent  any  confusion  between  its  short-form,  CBT, 
which  is  popularly  used  for  core-based  trees  [Ref.  2].  The  term  is  also  more  appropriate  for  the 
proposed  approach  based  on  distribution  centers. 

^We  view  a  Steiner  tree  to  be  a  special  case  of  a  CST  because  all  the  proposed  algorithms  for 
Steiner  trees  are  based  on  a  pre-selected  toot,  which  we  regard  as  a  center.  We  focus  not  on  the 
tree  quality  in  our  classification  but  on  the  protocol  for  tree  construction. 
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[Ref.  6].  Its  main  disadvantage  is  that,  when  the  number  of  simultaneous  senders  is 
likely  to  be  small  compared  to  the  total  number  requiring  a  guaranteed  QoS,  excessive 
reservation  of  network  resources  occurs.  Basically,  reservation  will  occur  along  every 
tree  although,  not  all  trees  will  carry  traffic  at  the  same  time. 

A  general  drawback  of  both  the  above  approaches  to  tree  construction  is  that 
they  are  mainly  concerned  with  routing  of  multicast  data  and  have  not  addressed  the 
techniques  to  provide  guaranteed  QoS.  The  ability  to  provide  a  guaranteed  quality 
of  service  depends  on  the  ability  to  reserve  resources.  Since  resources  are  consumed 
along  the  routes  taken  by  multicast  traffic,  it  is  natural  to  expect  that,  in  a  technique 
that  guarantees  QoS,  routing  be  coupled  with  reservation.  There  are  a  great  number 
of  ways  to  accomplish  this  goal.  The  different  requirements  for  each  application  will 
lend  themselves  to  different  ideal  ways  to  handle  the  problem.  To  attempt  to  find  the 
best  median  for  all  possible  applications  is  very  extensive  and  furthermore  hampered 
by  the  impossible  task  of  knowing  all  possible  applications. 

To  summarize  the  above  discussion,  we  observe  that  efficient  wide-area  multi¬ 
party  interactions  with  QoS  requirements  need  a  tree  construction  technique  that 
is  scalable  in  terms  of  the  number  of  participants  and  geographical  distribution  of 
members,  uses  network  resources  efficiently,  integrates  reservations,  and  requires  low 
tree-state  maintenence  overhead,  and  places  minimal  administrative  burden.  We  ad¬ 
dress  the  problem  of  providing  such  a  technique  for  tree  construction.  Our  approach 
is  targeted  at  multiparty  interactions  requiring  reservations  and  for  which  some  a 
priori  information  about  some  participants  is  available. 

A.  An  Integrated  Approach  based  on  Critical  Participants 

With  each  multiparty  interaction  mentioned  above,  a  critical  set  of  participants 
can  be  identified.  For  example,  in  a  teleconference,  any  quorum  of  participants 
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permits  the  meeting  to  perform  its  function.  Every  attendee  is  a  potential  sender 
and  a  receiver.  In  a  virtual  classroom,  the  lecturer  is  the  only  critical  participant. 
Any  number  of  students,  permitted  by  the  room  size,  may  be  present.  The  lecturer 
is  a  sender  as  well  as  a  receiver  and  the  students  are  only  receivers.  ®  However, 
their  presence  is  not  essential  for  the  class  to  go  on.  In  a  panel  discussion,  all  the 
panel  members  form  the  set  required  for  the  the  discussion  to  begin.  Any  number 
of  listeners  may  be  present.  In  order  to  keep  the  panel  effective,  it  should  at  least 
be  ensured  that  all  the  panelists  receive  every  other  panelist  with  a  guaranteed  QoS. 
In  a  remote  telemetry  application,  some  data  collector  must  exist  for  the  sensors  to 
send  data  to.  This  collector  forms  the  critical  set.  In  a  distributed  simulation/test 
environment,  all  the  entities  form  the  set  of  critical  participants.  In  a  virtual  cafe, 
the  critical  set  is  formed  dynamically  by  one  or  more  people  who  acknowledge  each 
other’s  desire  to  interact  and  try  to  establish  communication. 

It  is  important  to  note  that  the  primary  attributes  of  a  critical  participant  from 
the  network’s  perspective  are:  its  location,  the  interaction  it  wants  to  participate 
in,  and  its  frequency  of  sourcing  data  relative  to  other  participants.  We  use  these 
attributes  as  an  aide  to  determine  one  or  more  central  network  locations  for  critical 
participants  based  on  which  one  or  more  efficient  CSTs  can  be  built. 

Relying  on  critical  participants  also  solves  the  following  problem  eissociated  with 
tree  construction  for  the  participants  of  a  multiparty  interaction.  Finding  the  center 
for  a  multicast  shared  tree  requires  an  exhaustive  search.  In  addition,  when  the 
membership  is  dynamic,  the  ideal  center  will  also  move.  It  may  be  desirable  to  have 
a  relatively  static  tree,  that  is,  one  in  which  the  root  does  not  move.  For  this  case, 
the  tree  should  not  rely  on  temporary  members  for  determining  the  root  of  the  tree. 

’Of  coutse,  occasionally  a  student  may  become  a  sender.  However,  it  is  unrealistic  to  expect  the 
network  to  keep  the  resources  reserved  in  view  of  the  low  frequency  with  which  a  student  may  send. 
In  any  case,  the  teacher  is  expected  to  repeat  the  student’s  remarks  for  the  benefit  of  the  rest  of 
the  class. 


4 


Those  members  that  are  long-lived  and  possibly  produce  a  relatively  large  amount  of 
traffic  to  the  group  should  carry  the  most  weight.  As  we  have  seen,  these  members 
will  be  known  a  priori.  In  addition,  if  the  number  of  members  used  to  determine  the 
root  of  the  tree  is  small,  then  the  number  of  calculations  to  determine  the  center  can 
be  greatly  reduced. 

Using  critical  participants  also  provides  a  clean  approach  for  resource  reserva¬ 
tion.  While  it  is  impossible  to  anticipate  the  needs  of  dynamic  members,  the  tree  for 
the  critical  participants  can  be  constructed  based  on  whether  resources  are  available 
or  not.  The  network,  with  the  knowledge  of  the  critical  participants,  can  form  a  tree 
with  the  required  resources  well-before  the  interaction  begins.  This  follows  the  suc¬ 
cessful  model  of  day-to-day  life  in  which  pre-planned  activities  can  block  resources  as 
soon  as  the  planning  completes  and  resources  are  made  available  for  reservation  (com¬ 
munity  halls,  airline  seats,  opera  seats,  etc.)  whereas  unplanned  activities  run  the 
risk  of  resource  unavailability.  This  essentially  integrates  routing  with  reservation. 

B.  QoS  Parameters  of  Multicast  Multimedia  Communica¬ 
tion 

We  now  briefly  describe  the  QoS  requirements  of  multiparty  interactions  over 
packet-switched  networks  that  have  been  understood  so  far  by  the  community.  Multi- 
media  data  may  correspond  to  audio  packets,  video  packets,  slowly  changing  graphics, 
and  normal  bursty  data.  Each  has  its  unique  requirements  in  a  point-to-point  setting. 
The  problem  of  setting  up  a  multiparty  interaction  is  to  satisfy  these  requirements 
even  in  point-to-multipoint  cases. 
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TABLE  1.1:  QOS  PARAMETERS  FOR 

POINT-TO-POINT  CHANNELS 

Delay 

Loss  Prob. 

Bandwidth 

Conditions 

lESSESHI 

300  msec 

800  bits  (cons.) 

64  Kbps 

PCM,  8  bit  samples 

Video 

300  msec 

4.16  Kbits 
per  frame 

1.34Mbps 

0.25  screen, 
byte  stream, 

20:1  min.  comp. 

Graphics 

n/a 

n/a 

208  Kbps 

full  screen  window, 
0.5  sec  update, 
min  20:1  comp. 

Simulation 

PDU 

100-300 

msec 

0 

Application 

dependent 

Sensor  data 

Application 

dependent 

Application 

Application 

dependent 

1.  QoS  Requirements  of  Point-to-point  Channels 

The  QoS  required  by  a  point-to-point  channel  has  been  primarily  charac¬ 
terized  by  the  maximum  permissible  end-to-end  delay,  end-to-end  jitter,  and  loss 
probability  [Ref.  7].  For  packet-switched  networks,  however,  it  has  been  recently  es¬ 
tablished  that  end-to-end  delay  and  jitter  can  be  bounded  by  ensuring  that  a  channel 
receives  at  least  a  certain  amount  of  average  bandwidth  at  each  intermediate  router 
[Ref.  8].  Therefore,  providing  a  guaranteed  QoS  point-to-point  channel  amounts  to 
reservation  of  appropriate  bandwidth  at  each  intermediate  router.  Also,  by  providing 
an  appropriate  amount  of  buffering,  the  end-to-end  jitter  requirement  can  be  met. 
Typical  QoS  parameters  for  various  types  of  channels  are  summarized  in  Table  1.1 
[Ref.  9,  10]. 

A  number  of  these  sources,  with  or  without  a  need  for  synchronization 
among  them,  may  be  present  in  an  interaction.  Types  of  interaction  differ  based  on 
the  number  of  and  the  interrelationships  between  these  sources.  Based  on  the  num¬ 
bers  above,  we  describe  five  sample  interactions,  a  virtual  classroom,  a  teleconference, 
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a  panel  discussion,  and  a  distributed  interactive  simulation  below. 

2.  A  Virtual  Classroom 

In  this  interaction,  the  teacher  represents  the  CP  and  the  students  are  the 
receivers  who  may  join  and  leave  the  interaction  at  any  time.  Depending  upon  the 
operational  details  of  the  classroom,  only  the  student  audio  may  be  carried  back  either 
only  to  the  instructor  or  to  all  the  students  along  with  the  instructor.  Or,  both  the 
audio  and  video  from  each  student  may  be  carried  to  either  only  the  instructor  or  to 
all  the  students  along  with  the  instructor.  In  either  case,  it  does  not  seem  necessary 
that  reservations  are  needed  from  the  students  to  the  teacher  for  more  than  one 
student  at  a  time. 

Thus,  assuming  that  only  the  student  audio  is  carried  only  to  the  instructor, 
a  virtual  classroom  will  require  one  video  (the  instructor),  one  graphics  (the  board 
or  the  screen),  and  one  audio  channel  from  the  teacher  to  all  the  students.  One 
audio  channel  will  be  needed  from  all  the  students  to  the  instructor.  It  is  assumed 
that  the  students  ask  questions  only  when  the  instructor  solicits  them  and  that  the 
students  are  polite  enough  to  not  monopolize  the  audio  channel.  Synchronization 
will  be  required  among  the  channels  originating  at  the  teacher.  A  SST  rooted  at  the 
teacher  and  a  CST  rooted  at  an  appropriate  router  shared  by  all  the  students  will  be 
required. 

3.  A  Teleconference 

A  teleconference  is  much  like  a  virtual  classroom  in  terms  of  the  number  of 
simultaneous  senders.  The  number  of  receivers  is  likely  to  be  restricted  to  the  set  of 
conference  paxticipants.  Every  participant  is  a  potential  sender  and  is  always  a  re¬ 
ceiver.  A  meeting  is  usually  a  planned  interaction,  and  therefore,  all  the  participants 
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locations  are  expected  to  be  known  a  priori.  It  is  assumed  that  the  p2irticipants  are 
polite  enough  that  only  one  speaks  at  a  time.  It  is  likely  that  more  than  one  are  to 
be  permitted  to  speak  at  one  time.  However,  we  cannot  find  a  reason  for  requiring 
more  than  one  speaker  at  a  time. 

In  terms  of  the  number  of  channels,  each  participant  is  a  potential  sender 
to  a  video  channel,  a  graphics  channel,  and  an  audio  channel.  With  the  above 
restriction,  the  graphics  and  audio  channels  could  be  sent  over  a  shared  tree.  Each 
video  channel  could  be  sent  over  a  SST  to  enable  all  participants  to  have  a  window 
for  all  other  participants. 

4.  A  Panel  Discussion 

A  panel  discussion  has  the  same  characteristics  as  a  teleconference  combined 
with  a  panel  discussion.  There  are  only  a  few  potential  senders,  the  CPs,  and  a  large 
number  of  receivers  who  may  join  and  leave  the  interaction  at  any  time.  The  panelists’ 
locations  are  known  a  priori  and  are  unlikely  to  leave  in  the  middle  of  the  interaction. 
The  receivers’  membership  may  be  short-lived. 

A  video  channel  originating  at  each  of  the  panelists  must  be  distributed  to 
all  the  receivers  (including  the  panelists).  An  audio  and  a  graphics  channel  must  also 
reach  all  the  receivers  and  the  panelists.  Depending  upon  the  operational  details  of 
the  panel  discussion,  a  receiver  may  receive  the  live  video  of  every  panelist’s  face  along 
with  the  speaker’s  audio  and  graphics  channel  or  may  see  a  still  graphic  image  of  each 
and  a  live  video  of  only  the  current  speaker.  The  audio  and  graphics  each  receiver 
gets  must  be  synchronized  with  the  video  received.  Assuming  that  there  is  wastage 
in  transmitting  live  video  of  a  face  and  the  latter  option  is  selected,  the  current 
speaker’s  audio,  video,  and  graphic  channel  is  to  be  distributed  to  all  the  receivers 
as  well  as  panelists.  Thus,  a  CST  can  be  constructed  for  each  of  the  channels  with 
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the  core  located  with  respect  to  the  panelists  and  the  receivers  receiving  multicast 
traffic  from  the  distribution  center  (root)  of  this  CST. 

5.  A  Distributed  Interactive  Simulation 

In  a  distributed  interactive  simulation,  multiple  hosts  execute  simulator 
programs  simultaneously.  Each  simulator  sends  protocol  data  units  (PDUs)  to  all 
the  other  simulators  so  that  every  simulator’s  state  is  made  consistent  with  that  of 
all  the  others  periodically  [Ref.  11].  There  are  strict  latency  constraints  on  all  the 
PDUs  and  the  rate  of  generation  of  the  PDUs  from  a  simulator  depends  upon  its 
function  as  well  as  the  events  it  simulates.  In  terms  of  the  multicast  requirements,  a 
set  of  DIS  applications  presents  a  set  of  concurrent  senders  who  also  receive  all  the 
PDUs.  Recent  DIS  experiments  have  used  up  to  eleven  hosts  [Ref.  11],  but  in  the 
near  future,  this  number  may  grow  as  the  scope  of  the  simulations  grows. 

In  this  multiparty  interaction,  each  simulator  host  is  a  CP  that  needs  to 
construct  a  SST  rooted  at  itself  with  the  QoS  determined  by  the  PDU  constraints. 
In  this  case,  there  is  no  benefit  in  sharing  a  tree. 

6.  A  Command  and  Control  Scenario 

In  a  command  and  control  scenario  as  envisioned  in  COPERNICUS  [Ref.  12], 
two  of  the  many  infrastructure  related  applications  are  information-pull  and  creation 
of  a  consistent  tactical  picture  ashore  and  afloat. 

In  the  information-pull  application,  the  commander-in-chief  (CINC)  will 
determine  the  sources  from  where  information  is  to  be  gathered.  This  will  result  in 
multiple  concurrent  sources  sending  to  one  or  more  sites  at  which  the  CINC  needs  the 
information  sent.  However,  this  set  of  sources  is  likely  to  be  a  subset  of  a  much  larger 
set  of  information  producing  sites.  Since  the  total  number  of  possible  sources  is  likely 
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to  be  much  larger  than  the  number  of  sources  required  in  any  single  information- pull 
operation,  a  shared  CST  rooted  at  an  appropriately  located  center  will  be  more 
efficient. 

In  the  creation  of  a  consistent  tactical  picture,  every  source  contributing  to 
such  a  picture  must  update  all  the  sites  that  maintain  the  picture.  At  any  time,  the 
sources  that  actually  generate  information  will  be  determined  by  the  geographical 
area  in  which  the  relevant  events  take  place.  If  such  events  can  be  anticipated, 
non-concurrent  sources  in  an  axea  could  share  CSTs.  The  centers  of  these  trees  act 
as  sources  for  ail  the  recipients  ashore  and  afloat.  SSTs,  where  the  centers  of  the 
lower  level  CSTs  become  sources,  need  to  be  constructed  since  every  lower  level  CST 
could  have  at  least  one  sensor  that  is  active  ail  the  time.  This  leads  to  a  two-level 
combination  of  CSTs  and  SSTs. 

C.  Scope  and  Contributions 

This  thesis  addresses  the  problem  of  constructing  multicast  trees  with  guaran¬ 
teed  QoS  that  utilize  the  network  resources  efficiently.  Efficient  usage  implies  load 
balancing  as  well  as  use  of  minimum  amount  of  resources  for  any  one  tree.  It  focuses 
on  how  to  achieve  an  efficient  combination  of  CSTs  and  SSTs  based  on  the  a  priori 
information  about  the  participants,  locate  a  center  for  CSTs  transparently  to  balance 
the  network  load,  and  integrate  reservation  with  routing. 

The  contributions  are  as  follows: 

•  A  systematic  approach,  based  on  the  critical  participants,  is  described  to  select 
a  combination  of  CSTs  and  SSTs  for  an  interaction. 

•  A  robust  and  scalable  center  location  mechanism  and  protocol  that  selects  a 
center  transparently  in  a  distributed  fashion  and  balances  the  network  reserva¬ 
tions  is  described. 


- - 

I 

•  It  is  shown,  by  simulation  modeling,  that  CSTs  based  on  center  location  as 
above,  provide  almost  the  same  delay  as  SSTs. 

•  It  is  shown,  by  simulation  modeling,  that  CSTs  are  efficient  when  the  number 
of  concurrent  senders  is  small  as  compared  to  the  number  of  participants. 

•  It  is  also  shown  that  CSTs  with  centers  located  as  above  compare  very  well 
with  Steiner  trees. 

D.  Thesis  Organization 

This  thesis  is  organized  as  follows.  Chapter  II  describes  our  design  goals  and 
related  justifications.  Chapter  III  reviews  current  approaches  by  listing  the  short¬ 
comings  of  each  approach  with  respect  to  these  design  goals.  Chapter  IV  describes 
our  approach  in  detail  and  introduces  the  mechanisms  required  for  implementing 
it.  Chapter  V  specifies  the  mechanisms  individually  and  exposes  their  interrelation¬ 
ships.  Chapter  VI  describes  the  simulation  modeling,  performeince  related  data,  and 
analysis  for  our  approach  to  tree  construction.  Chapter  VII  reviews  some  of  the 
currently  proposed  schemes  for  low-level  handling  of  unicast  packets  with  respect  to 
their  suitability  to  guaranteed  QoS  multicast.  The  thesis  concludes  by  a  summary  of 
the  strengths  and  weaknesses  of  the  proposed  approach  and  the  future  work  required. 
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II.  Design  Goals 


In  this  chapter,  we  describe  the  desirable  features  of  multicast  tree  construction 
when  guaraaiteed  QoS  is  desired. 

Use  of  a  priori  Information  About  Participants:  As  seen  in  the  previous  chap¬ 
ter,  every  interaction,  except  for  the  virtual  cafe  type,  has  some  element  of 
planning  in  it.  In  fact,  typically,  considerably  more  information,  such  as  prob¬ 
able  senders’  locations,  critical  receivers,  relative  rates  of  sourcing  data,  etc.,  is 
available.  It  is  natural  that  this  information  be  used  in  configuring  multicast 
trees. 

When  such  information  is  used,  it  adds  several  desirable  features  to  the  quality 
of  trees  constructed.  For  example,  the  tree  topology  incorporating  the  relatively 
long-lived  and  important  group  members  remains  static.  Short-lived  members 
affect  the  topology  only  by  grafting  the  appropriate  branches.  The  tree  com¬ 
putation  can  be  performed  only  for  a  small  subset  of  the  important  members. 
The  number  of  distribution  centers  can  be  made  proportional  to  the  number 
of  concurrent  senders.  Essentially,  an  efficient  compromise  between  SST  and 
CST  can  be  reached  for  the  given  group. 

Automatic  Location  of  Distribution  Centers:  In  a  rich  network  topology,  the 
SSTs  for  a  set  of  senders  are  more  likely  to  be  different  from  each  other  than 
in  a  poor  network  topology.  Thus,  in  a  rich  topology  with  many  multicast 
groups,  SSTs  are  likely  to  balance  the  network  utilization  better  than  CSTs 
which  are  all  constructed  based  on  the  same  administratively  located  center 
[Ref.  2,  13].  This  goal  requires  that  distribution  centers  must  be  located  for 
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each  specific  set  of  group  members.  If  the  current  reservation  in  the  network  is 
taken  into  account  while  locating  such  a  center,  the  resulting  CST  will  not  only 
balance  the  network  usage,  but  will  also  balance  the  reserved  bandwidth  usage. 
Goal  1  above  is  complementary  to  this  goal  in  that  the  participants’  attributes 
registered  according  to  it  must  be  used  to  locate  the  center  transparently  for  a 
group. 

Flexible  Selection  Between  Source-specific  and  Center-specific  Trees:  CSTs 
and  SSTs  present  a  clear  trade-off  when  reservations  are  required.  SSTs  reserve 
less  when  the  number  of  concurrent  senders  is  large  and  CSTs  reserve  less  when 
this  number  is  small.  Ideally,  the  set  of  senders  should  be  partitioned  into  sub¬ 
sets  in  such  a  way  that  at  least  one  sender  from  the  subset  is  active  at  any 
time.  A  separate  SST  should  be  constructed  for  each  such  set  with  the  senders 
in  the  subset  sharing  a  CST.  The  center  of  the  subset  should  be  the  root  for 
the  SST.  This  will  minimize  the  number  of  reservations  in  the  network.  For 
enabling  this  efficiency,  a  flexible  selection  between  SSTs  and  CSTs  must  be 
permitted  by  the  tree  construction  mechanism. 

Integration  of  Tree  Setup  with  QoS:  In  any  situation  that  demands  guaranteed 
resource  availability,  it  is  imperative  that  reservations  be  made  as  soon  as  the 
later  of  the  two  events  occurs  -  resources  become  available  for  reservation  and 
it  is  known  which  resources  are  to  be  reserved.  This  successful  model  of  day-to- 
day  life  must  be  followed  in  a  dynamic  environment  such  as  an  internet.  The 
length  of  the  interval  between  the  granting  of  the  permission  to  reserve  and 
the  expected  start  of  the  interaction  could  be  based  on  the  service  charges.  At 
the  start  of  this  interval,  which  resources  are  needed  could  be  determined  by 
initiating  the  tree  construction  mechanism.  This  mechanism  must  be  sensitive 
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to  which  parts  of  the  network  are  already  heavily  booked.  ToS-related  costs 
need  to  be  used  to  determine  the  shortest  paths.  These  actions  integrate  reser¬ 
vations  for  guaranteed  QoS  with  tree  construction  instead  of  providing  them 
as  an  afterthought  [Ref.  13]. 

Support  of  Multiple  Routing  Protocols:  Given  that  different  routing  domains 
in  an  internet  are  likely  to  use  different  routing  protocols,  a  practical  tree 
construction  approach  must  be  compatible  with  them.  It  must  also  not  impose 
ajiy  additional  state  collection  overhead  of  its  own.  Ideally,  it  should  use  some 
generic  measure  of  network  state  that  any  intra-domain  routing  protocol  would 
collect.  The  cost  of  a  path  between  two  nodes  inside  a  domain  is  one  such 
measure. 

Minimal  Tree  State  Information:  It  is  expected  that  multiparty  interactions  de¬ 
scribed  earlier  will  lead  to  sparse  as  well  as  loccilly  dense  distributions  of  a  large 
number  of  members  in  a  group.  Membership  of  senders  as  well  as  receivers  is 
expected  to  be  dynamic.  A  new  sender  as  well  as  receiver  should  suffer  as  small 
latency  as  possible.  An  extreme,  yet  possible,  solution  is  that  every  router  in 
the  internet  maintain  state  related  to  every  group,  and  possibly,  every  sender  in 
each  group.  Clearly,  this  solution  is  not  scalable  at  all.  The  PIM  proposal  re¬ 
quires  each  router  aware  of  the  group  store  state  information  for  each  sender  of 
the  group  [Ref.  13].  On  the  other  hand,  the  CBT  approach  requires  each  router 
to  maintain  information  for  the  core  of  each  group  [Ref.  2].  We  require  that 
minimum  possible  join  latency  be  achieved  while  keeping  the  state  information 
stored  by  each  router  minimum. 

Minimal  Per-packet  Processing  in  the  Routers:  It  is  observed  that  the  tree 
state  information  maintained  by  PIM  is  eliminated  in  CBT  at  the  expense  of 
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additional  per  packet  processing  [Ref.  2].  We  require  that  the  proposed  protocol 
keep  this  overhead  in  routing  multicast  traffic  low. 

Participation  of  the  Senders  as  well  as  Receivers  in  Reservation:  Receiver- 
initiated  approach  has  been  suggested  as  a  scalable  approach  to  reservation 
that  is  independent  of  the  protocol  used  for  routing  and  for  tree  construction 
[Ref.  6].  This  approach  requires  that  the  internet  paths  be  symmetric.  In  an 
interaction  where  the  set  of  receivers  is  relatively  dynamic,  each  new  receiver 
must  create  reservations  for  receiving  traffic  from  all  the  senders.  On  the  other 
hand,  if  the  senders  are  relatively  long-lived,  it  should  not  be  required  that  the 
entire  reserved  path  from  each  sender  be  created  for  every  new  receiver.  We 
require  that  the  burden  of  creating  reserved  paths  be  shared  flexibly  by  both 
the  senders  as  well  as  receivers. 
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III.  Comments  on  Existing  Approaches 


A.  Core*based  Trees 

A  current  technique  that  sets  up  a  single  shared  tree  is  the  Core  Based  Tree 
proposal.  For  this,  a  router  is  chosen  as  the  root,  or  core,  of  the  tree  for  adminis¬ 
trative  purposes.  New  branches  of  the  tree  are  created  at  the  time  of  propagation  of 
the  join  ack  message  sent  by  the  first  on-tree  router  that  receives  a  join  request  from 
a  new  member.  The  join  request  and  auck  are  propagated  using  unicast  methods.  A 
multicast  packet  from  the  sender  propagates  towards  the  core  (which  is  the  packet 
destination  address)  using  normal  unicast.  When  it  hits  an  on-tree  router,  its  desti¬ 
nation  address  is  replaced  by  the  multicast  group  address  found  in  the  packet  header 
and  is  then  disemenated  as  a  multicast  message  on  the  tree. 

One  nice  feature  of  CBT  is  that,  for  new  senders  as  well  as  non-receiving  senders, 
any  unicast  algorithm  works.  The  main  advantages  of  a  core  are  as  follows.  Firstly,  it 
provides  a  group  startup  mechanism  in  that  the  first  member  has  direction  in  which 
to  send  its  traffic  which  is  correct  even  if  another  member  h^ls  joined  the  group  almost 
simultaneously.  Secondly,  it  provides  a  destination  for  all  routers,  on-tree  or  not,  to 
route  any  multicast  packets.  Thirdly,  once  the  tree  hais  been  formed,  the  failure  of 
the  core  is  treated  in  the  same  feishion  as  the  failure  of  any  other  on-tree  router.  If  a 
hierarchy  of  routers  is  defined  a  priori,  the  tree  automatically  reconfigures  with  the 
secondary  router  as  the  core. 

The  shortcomings  of  this  approach  are  that  the  mapping  of  core  addresses  to 
group  addresses  is  not  addressed.  Particularly,  if  group  addresses  are  to  be  assigned 
dynamically  when  they  become  a  scarce  commodity,  it  will  not  sit  well  with  the  fact 
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that  the  cores  are  determined  statically  (administratively).  There  is  no  easy  way 
to  locate  the  core.  If  a  multicore  tree  is  envisioned,  this  problem  becomes  more 
acute.  Since  CBT  is  proposed  is  an  interdomain  routing  technique,  the  interdomain 
links  will  quickly  become  bottleneck  links.  The  same  problem  occurs  when  multiple 
senders  send  simultaneously. 

B.  Protocol  Independent  Multicast 

Protocol  Independent  Multicast  (PIM),  formerly  known  as  E.xplicit  Source  List 
(ESL)  [Ref.  13]  is  a  proposal  for  dealing  with  “'skinny  trees’'.  This  refers  to  a  group 
that  is  sparsely  spread  throughout  the  internetwork.  Current  schemes  for  multi¬ 
casting  have  routers  assume  that  everyone  wants  the  multicast  unless  the  router 
determines,  via  IGMP,  that  no  members  exist  down  a  given  path.  Messages  were 
constrained  in  their  distance  travelled  by  their  Time  To  Live  (TTL)  parameter  in  the 
packet  header.  This  leads  to  a  problem  when  there  are  members  sparsley  populated 
throughout  different  networks.  To  include  the  distant  members,  the  TTL  needs  to 
be  increased.  This,  in  turn,  requires  many  more  routers  to  search  for  paths  with  no 
members  and  so  greatly  increases  the  amount  of  traffic.  PIM  is  proposed  to  eliminate 
this  inefficiency. 

PIM  is  centered  around  router(s)  designated  as  Rendezvous  Points  (RP).  For 
each  group  a  number  of  routers  will  be  appointed  as  RPs.  A  RP  is  a  focal  point  for 
members  of  a  group  in  a  given  area.  Once  a  receiver  is  connected  to  the  RP,  it  can 
learn  who  the  sources  are  via  aji  IGMP-Register  message.  Once  this  is  known,  the 
receiver  can  elect  to  receive  messages  via  the  shortest  path  from  the  source  rather  than 
via  the  RP.  Routers  axe  then  informed  of  this  decision,  so  that  they  can  reconfigure 
if  necessary,  by  an  IGMP-ESL  message.  This  technique  then  provides  a  means  by 
which  a  source  specific  shortest  path  tree  can  be  formed  without  flooding  the  network 
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as  routers  find  branches  with  non-members.  The  authors  point  out  that  if  there  is 
a  large  number  of  sources  with  low  data  rates  that  the  group  would  continue  to  use 
the  RPs  and  hence  would  have  a  shared  tree. 

Shortcomings  of  this  proposal  are  that  the  routing  is  determined  by  Reverse 
Path  Forwarding.  This  means  that  the  trees  created  are  from  the  shortest  paths 
from  the  receivers  to  the  source  rather  than  source  to  the  receivers.  This  can  create 
incorrect  trees  when  routes  are  asymmetric.  Another  limitation  is  the  need  for  PIM 
routers.  These  routers  need  to  become  aware  of  the  RPs  for  each  group.  If  the  PIM 
router  does  not  recognize  the  group,  i.e.  it  does  not  have  a  RP  mapping  for  that 
group,  it  assumes  that  the  multicast  is  not  to  be  supported  by  PIM.  If  the  TTL  is 
large  then  the  network  will  be  flooded  until  it  leaxns  of  the  tree. 

PIM  is  designed  to  help  prevent  congestion  at  choke  points  which  would  be  the 
root  of  a  shared  tree.  But  PIM  requires  that  all  senders  include  all  RPs  on  their 
individual  tree  so  that  newly  joining  members  can  begin  to  receive  traffic.  This 
means  that  all  RPs  will  have  a  large  amount  of  incoming  traffic  whether  or  not  the 
RP  has  any  members  in  which  to  route  the  traffic.  For  the  input  case  for  the  RPs 
then,  it  will  be  no  different  than  a  root  of  a  single  shared  tree  except  it  occurs  for 
every  RP  that  exists  for  the  group.  For  robustness  sake,  multiple  RPs  are  required 
for  each  group.  It  appears  that  congestion  will  not  be  relieved  at  all  and  possibly 
traffic  is  routed  where  it  is  not  needed. 

C.  Distance  Vector  Multicast  Routing  Protocol 

Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  [Ref.  4]  is  a  multicast 
protocol  derived  from  Routing  Information  Protocol  (RIP)  [Ref.  14]  and  Internet 
Group  Management  Protocol  (IGMP)  [Ref.  15].  It  makes  use  of  Truncated  Reverse 
Path  Broadcasting  (TRPB)  [Ref.  1]  which  is  essentially  an  efficient  form  of  flooding 
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while  incorporating  a  technique  known  as  “pruning”.  Pruning  prevents  the  message 
from  being  delivered  to  nets  that  have  no  members  or  are  not  on  the  shortest  path 
from  the  sender  to  other  routers. 

TRPB  makes  use  of  distance  vector  routing  tables  to  minimize  duplicate  packets 
sent  out  on  the  network.  These  allow  “parent”  and  “child”  relationships  to  be  set 
up.  A  child  router  depends  on  the  parent  router  to  forward  packets  from  a  given 
sender,  i.e.  the  parent  router  is  on  the  shortest  path  from  the  child  to  the  sender. 
Neighboring  routers  share  their  information  on  distance  to  the  sender  so  that  they 
can  discover  the  shortest  path  to  the  sender  and  aJso  determine  which  is  the  dominant 
router  if  they  both  service  the  same  net.  The  router  that  is  determined  to  be  the 
dominant  router  is  the  one  to  service  that  net.  The  other  router  will  not  send  ajiy 
packets  to  that  net  as  they  would  only  be  duplicates.  If  both  routers  are  equal  distant 
to  the  sender  then  the  dominant  router  is  the  one  with  the  largest  IP  address. 

In  addition  to  parent  and  child  relationships  between  routers,  there  is  the  possi¬ 
bility  of  a  “leaf”  relationship  between  a  router  and  a  net.  A  net  is  considered  a  leaf  if 
no  other  routers  consider  that  net  as  part  of  the  shortest  path  to  the  sender  i.e.  there 
are  no  parent/child  relationships  across  that  net.  If  a  network  is  determined  to  be 
a  leaf  and  there  are  no  members  of  the  group  on  that  net,  then  the  router  correctly 
determines  that  there  is  no  need  to  deliver  the  multicast  packet  to  that  net.  This 
again  helps  reduce  the  number  of  needless  packets  delivered. 

DVMRP  is  for  use  only  within  an  autonomous  system.  As  can  be  seen  every 
router  receives  the  packet.  TRPB  merely  prevents  the  delivery  of  duplicate  packets. 
The  only  areas  a  packet  is  not  delivered  to  is  a  leaf  network  with  no  members, 
which  gets  pruned.  Future  implementations  of  DVMRP  hope  to  use  Reverse  Path 
Multicasting  (RPM)  [Ref.  1].  This  is  more  efficient  because  it  will  enable  the  pruning 
of  routers  that  have  no  members  of  the  group  downstream  of  itself. 
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Disadvantages  of  DVMRP  ar*  that  the  packet  may  be  delivered  to  locations 
where  it  is  not  needed.  It  is  limited  in  scope  to  within  an  autonomous  system. 
Current  methods  use  distance  to  the  sender,  for  asymmetric  links,  the  shortest  path 
may  not  be  discovered.  It  has  been  mentioned  that  it  is  possible  to  use  the  reverse 
distant  cost  so  that  the  actual  forwarding  cost  from  the  sender  would  be  used  and 
avoid  the  asymmetry  problem.  But  this  will  double  the  size  of  routing  tables  because 
unicast  uses  the  previous  metric  to  determine  the  shortest  path  to  the  receiver. 

D.  MOSPF 

MOSPF  [Ref.  3]  is  the  multicast  extension  of  the  link-state  protocol  known  as 
OSPF  [Ref.  16].  This  method  is  for  use  within  an  Autonomous  System  (AS)  and 
not  over  the  entire  Internet.  With  link-state,  all  routers  know  the  distance  to  all 
destinations  within  the  AS.  To  add  a  multicast  capability,  a  new  link  advertisement 
message  is  made.  This  message  lets  all  the  other  routers  know  where  members  of  a 
multicast  group  lie.  MOSPF  utilizes  IGMP  for  the  routers  to  discover  hosts  belonging 
to  the  group.  This  means  that  every  router  can  determine  the  source  based  multicast 
tree  for  every  source/group  pair  in  the  AS.  Once  this  is  done  the  router  caches  the 
output  interfaces  for  each  source/group  pair  for  future  use. 

To  add  the  ability  for  multicasts  to  enter  or  leave  the  MOSPF  AS,  the  border 
routers,  (those  adjacent  to  neighboring  AS‘s  become  wildcard  members,  that  means 
that  they  are  automatically  members  of  every  group.  This  allows  all  multicast  mes¬ 
sages  to  reach  the  next  domain.  The  TTL  of  the  message  can  be  set  so  as  to  limit 
the  scope  of  the  message. 

The  shortcomings  of  this  approach  are  the  extensive  calculations  required  for 
every  router  to  determine  the  source  based  tree.  This  will  be  done  for  every  source 
for  the  group.  The  author  points  out  that  these  calculations  will  be  made  on  demand 
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■  1:  EXISTING  A 


Goal 


Utilize  a  priori  information 


Automatic  locating  of  the  DC’s 


Flexible  choice  of  tree  type 


Tree  setup  with  QoS 


Support  multiple  routing  protocols 


Minimal  tree  state  information 


Minimal  router  processing 


so  as  to  spread  the  computations  over  time  and  prevent  unnecessary  work  for  the 
processor  in  figuring  out  trees  for  non-existent  source/group  pairs.  In  addition  when 
the  state  changes  in  the  net,  it  is  not  clear  if  the  entire  tree  will  need  to  be  recalculated 
for  every  source  or  if  the  computations  can  be  made  so  as  to  only  update  the  affected 
interfaces  of  the  source/group  pairs.  Membership  reports  are  sent  to  all  routers  so 
unneeded  information  may  be  promulgated  and  take  up  memory. 

Another  point  is  with  the  use  of  source  based  trees.  The  caches  of  the  routers 
will  need  to  be  large  because  of  the  possibility  of  groups  with  a  large  number  of 
sources.  If  more  than  one  source  for  a  given  group  uses  the  exact  same  interfaces  at 
a  router,  there  will  still  be  seperate  cache  entries  for  each  source. 

E.  Comparison  against  Design  Goals 

See  Table  3.1  for  a  comparison  of  the  above  mentioned  approaches  to  the  design 
goals.  DVMRP  and  MOSPF  are  considered  to  automatically  locate  the  Distribution 
Centers  because  they  automatically  use  a  SST. 
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IV.  General  Approach 


In  view  of  the  shortcomings  of  current  approaches  described  in  the  previous 
chapter  and  the  design  goals  outlined  earlier,  the  proposed  approach  has  been  de¬ 
veloped  with  distinct  aspects.  They  are:  actions  taken  by  the  network  based  on  a 
priori  information  available  about  the  upcoming  interaction,  group- specific  location 
of  one  or  more  cores  and  establishment  of  corresponding  trees,  changes  in  the  trees’ 
topologies  due  to  the  dynamic  multicast  group  membership,  and  reservation  of  re¬ 
sources.  In  this  chapter,  we  describe  each  of  these  aspects  and  relate  it  to  the  design 
goals  justified  earlier.  The  mechanisms  to  be  provided  by  the  network  to  implement 
this  approach  are  described  in  the  next  chapter. 

A.  Assumptions 

Following  are  the  assumptions  in  our  approach.  We  have  assumed  that  the 
network  links  are  bidirectional  and  the  costs  are  symmetric.  In  other  words,  the  cost 
of  going  from  A  to  B  is  the  same  as  the  cost  of  going  from  B  to  A.  While  it  is  claimed 
[Ref.  13]  that  most  of  the  current  Internet  links  are  symmetric  in  their  ca,  icities,  it 
is  unrealistic  to  expect  that  the  traffic  load  on  any  link  be  symmetric.  This  makes 
our  assumption  rather  severe;  however,  we  plan  to  address  this  problem  in  the  future. 
We  do  outline  llie  impact  of  relaxing  this  assumption  in  the  laist  chapter. 

In  the  current  Internet  multicast,  membership  in  a  group  only  affects  a  member’s 
ability  to  receive  multicast  traffic  to  the  group.  However,  members  as  well  as  non¬ 
members  can  send  to  a  group.  We  assume  the  existence  of  some  security  mechanism 
that  forces  a  sender  to  first  become  a  member. 
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We  also  assume  that  if  two  senders  are  topologically  close,  the  local  routing 
algorithm  will  not  give  two  almost  independent  paths  to  a  distant  node  (such  as  a 
core).  The  case  when  this  happens  is  illustrated  in  Fig.  4.1(a).  This  permits  us 
to  not  worry  about  the  case  that  two  nearby  sources  will  lead  to  reservations  along 
separate  paths.  In  case  of  CBTs  (or  shared  trees),  this  assumption  merely  implies 
that,  as  multicast  packets  progress  towards  the  core,  they  seek  the  shortest  path  (SP) 
as  well.  One  problem  with  attempting  to  distinguish  the  SP  to  the  core  from  the  SP 
to  the  group  (which  may  be  shorter  as  illustrated  in  Fig.  4.1(b))  is  that  it  is  difficult 
to  determine  at  what  point  the  SP  to  the  group  is  to  be  preferred  over  the  SP  to  the 
core.  Determining  this  cross-over  point  requires  the  more  general  trade-olF  between 
resource  consumption  and  delay  in  the  tree  construction  mechanism  itself.  We  have 
elected  to  address  this  trade-off  at  the  group  level  rather  than  individual  member 
level  by  locating  multiple  distribution  centers  for  a  group  if  necessary.  If  a  single 
distribution  center  exists  for  a  multicast  group  as  in  CBT  [Ref.  2],  the  difference 
between  the  distances  to  the  nearest  group-aware  router  and  to  the  core  is  likely 
to  be  high.  In  this  case,  SP  to  the  group  is  likely  to  result  in  reservation  of  fewer 
resources  on  the  whole  whereas  SP  to  the  core  will  minimize  the  average  delay. 

With  a  dynamic  group  membership,  it  is  difficult  to  make  a  packet  seek  the 
shortest  path  to  the  group  in  practice  (it  is  not  known  which  way  leads  to  the  closest 
member).  A  group  member  that  is  not  directly  connected  to  any  router  that  is  aware 
of  the  required  group,  relies  on  some  protocol  like  IGMP  [Ref.  15]  to  reach  a  router 
that  is  group-aware.  In  the  future,  we  expect  that  the  new  member  could  rely  on 
some  hierarchical  global  group  membership  service  that  associates  a  group  name  with 
the  address  of  the  nearest  distribution  center. 
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Figure  4.1:  Illustration  of  assumptions 
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B.  Use  of  a  priori  Information  About  the  Participants 

In  our  approach,  depending  upon  the  nature  of  the  multiparty  interaction,  it  is 
desired  to  minimize  network  resources  that  need  to  be  reserved  by  striking  a  com¬ 
promise  between  shared  CSTs  and  SSTs.  The  nature  of  a  multiparty  interaction  is 
determined  by  the  following  three  parameters:  reservation  requirements  of  individual 
CPs,  number  of  simultaneous  senders,  and  the  geographical  distribution  of  members. 
We  anticipate  a  network  entity,  called  a  scheduling  register  (SR),  similar  to  the  session 
directory  (sd)  tool  developed  by  Van  Jacobson  [Ref.  17],  that  permits  participants  to 
register  and  declare  these  requirements.  Every  participant  should  know  its  reserva¬ 
tion  requirements  (bandwidth)  and  its  address  (location).  It  can  also  be  expected  to 
know  its  sending  requirements  as  they  relate  to  the  role  (function)  it  will  play  in  the 
interaction.  This  will  permit  the  SR  to  determine  if  this  sender  is  required  to  send 
concurrently  with  the  other  senders. 

Based  on  this  information  supplied  by  all  the  participants,  the  SR  can  deduce 
the  amount  of  bandwidth  required  by  each  and  the  distribution  of  the  CPs.  The  SR 
can  also  group  all  the  CPs  into  subsets  such  that  no  two  CPs  in  a  subset  send  at 
the  same  time  and,  at  any  time,  there  is  at  least  one  CP  from  the  subset  with  send 
traffic.  We  refer  to  each  of  these  groups  as  a  critical  set  of  participants  (CSP). 

This  grouping  is  justified  by  our  viewpoint  that  the  CPs  of  any  interaction  group 
can  be  grouped  into  one  or  more  CSPs  depending  upon  their  sending  and  reservation 
requirements,  and  geographical  distribution.  If  a  certain  CP  is  expected  to  be  sending 
throughout  the  interaction,  a  sender-based  SST  should  be  formed  to  deliver  its  traffic 
most  efficiently  (with  the  leeist  delay  and  minimum  reservation  of  resources)  to  all 
the  receivers.  On  the  other  hand,  if  a  subset  of  CPs  is  likely  to  have  only  one 
sender  among  them  at  any  time  and/or  send  for  only  a  part  of  the  interaction,  they 
should  shaje  a  tree.  Moreover,  CPs  that  are  in  distant  and  separate  routing  domains 
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should  not  share  a  tree.  Thus,  our  approach  proposes  a  way  of  creating  an  efficient 
combination  of  shared  and  sender-based  trees  for  a  given  interaction. 

C.  Locating  a  Set  of  Distribution  Centers 

The  shared  tree  approach  is  criticized  for  being  prone  to  congestion  on  the 
backbone  links  in  case  of  multiple  simultaneous  interactions.  For  rich  topologies,  Wei 
and  Estrin  [Ref.  5]  show  that  sender-based  SPTs  distribute  bandwidth  requirements 
more  evenly  than  CBTs  although  their  overall  requirement  for  a  group  is  higher. 
This  is  due  to  the  fact  that  the  core  for  the  shared  tree  is  located  administratively 
regardless  of  the  locations  of  the  members. 

It  has  also  been  shown  that  constructing  a  multicast  tree  naively  is  almost  as 
good  as  some  optimized  technique  [Ref.  18].  However,  this  analysis  does  not  account 
for  other  simultaneous  multicasts,  and  therefore,  cannot  be  applied  to  multiple  simul¬ 
taneous  multiparty  interactions.  Wei  and  Estrin  [Ref.  5]  claim  that  a  member-based 
SPT  is  almost  as  good  as  an  optimal  CBT.  However,  which  member  is  selected  is  not 
specified.  It  seems  that  for  widely  distributed  groups,  this  member’s  location  will  be 
critical  to  the  tree  quality. 

In  our  approach,  we  specify  a  mechanism  for  the  network  to  determine  a  set 
of  router  locations  as  distribution  centers  for  the  interaction.  It  provides  a  way  of 
selecting  a  distribution  center  (which  performs  the  same  function  as  the  core  of  a  CBT 
or  a  rendezvous  point  of  PIM)  for  each  CSP.  Being  dependent  on  the  CP  locations 
in  a  CSP,  such  selection  of  the  center  leads  to  the  construction  of  the  shared  CST 
in  a  manner  that  distributes  the  resource  usage  across  the  network  uniformly.  This 
can  be  achieved  by  maximizing  the  resources  that  remain  available  in  the  network 
while  selecting  the  center  location.  Our  approach  of  dividing  the  CPs  into  CSPs  for 
formation  of  a  shared  trees  based  on  the  CP  attributes  includes  cases  when  a  CSP 
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must  contain  only  one  CP  and  the  core  gets  located  at  the  sender  itself  resulting  in  a 
sender-based  tree.  Essentially,  this  leads  to  the  establishment  of  multiple  centers  with 
a  QoS  tree  originating  at  each.  We  describe  the  approach  to  selecting  the  location 
of  a  center  for  a  single  CSP  below. 

1.  Selecting  the  Location  of  a  Distribution  Center 

The  principal  requirements  for  the  location  of  a  distribution  center  are  that 
it  should  be  fast,  scalable,  and  produce  trees  with  the  required  quality  while  using  as 
few  network  resources  as  possible.  It  should  also  produrp  crees  that  distribute  center 
locations  in  the  network  based  on  the  locations  of  the  CPs.  In  our  approach,  we  rely 
on  an  administrative  mechanism  of  SR  to  inform  the  CPs  about  the  CSP  they  are 
in.  The  SR  also  provides  a  CP  id  to  each  CP  within  a  CSP.  Each  CP  identifies  itself 
as  belonging  to  a  CSP  id  assigned  by  the  SR.  The  routers  corresponding  to  CPs  with 
the  same  CSP  id  then  enter  a  distributed  pair-wise  selection  process  that  results  in 
the  selection  of  a  center.  For  each  CSP,  the  SR  describes  the  complete  hierarchy  of 
pairings  used  for  center  selection.  Using  this  hierarchy,  a  single  center  is  located  and 
a  shortest  path  tree  is  established  as  the  tree  shared  by  the  senders  in  that  CSP  of 
the  multicast  group. 

There  are  several  aspects  of  such  center  selection  that  need  to  be  specified. 
Firstly,  the  SR  has  the  responsibility  to  provide  the  complete  pairing  hierarchy  for 
all  the  phases  of  the  selection  process.  Each  phase  represents  a  pair-wise  selection  of 
a  router  location  for  a  pair  of  router  locations.  The  router  location  selected  (called 
the  winner)  for  a  pair  can  be  some  router  (preferably  at  the  center)  along  the  path 
between  the  two.  Since  the  home  routers  of  the  CPs  themselves  participate  in  the 
first  phase,  such  pairing  can  be  done  based  on  the  inter-CP  distances  by  the  SR.  Note 
that  this  is  possible  only  in  the  first  phase  since  CP  locations  are  known  to  the  SR. 
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However,  the  locations  selected  in  the  second  phase  onwards  are  not  known  a  priori 
to  the  SR.  Therefore,  pairing  in  the  subsequent  phases  is  done  without  any  additional 
distance  information.  A  deterministic  algorithm,  based  on  the  CP  id  within  a  CSP, 
determines  the  pairs  in  each  of  the  phases.  The  SR  executes  this  algorithm  and 
distributes  the  selection  hierarchy  to  each  CP  in  a  CSP.  The  detciiled  algorithm  is 
given  in  the  next  chapter. 

In  the  first  phase,  locations  that  are  farthest  apart  are  paired  off.  The  SR 
can  derive  such  information  easily  from  the  unicast  routing  databases  at  a  router. 
The  justification  for  pairing  off  the  most  distant  locations  is  that  the  central  location 
is  determined  more  quickly.  Using  the  stime  argument,  we  require  that,  if  a  winner 
has  no  partner  in  a  particular  phase  (there  are  an  odd  number  of  them),  it  must  be 
paired  off  at  the  earliest  opportunity  in  the  subsequent  phases.  This  ensures  that  a 
far-flung  location  will  have  the  least  impact  on  the  final  winner’s  location.  Note  that 
if  such  a  location  is  paired-off  when  a  center  is  determined  for  all  the  other  locations, 
the  final  center  location  can  be  displaced  considerably  from  the  network  center  of 
the  CSP  as  compared  to  the  case  when  it  is  paired-off  at  the  earliest  opportunity. 
Generalizing  this,  we  require  that  the  SR  determines  an  inverted  tree  of  locations, 
with  the  CPs  at  the  top  (leaves),  that  minimizes  the  number  of  successive  bye  phaises 
for  a  particular  location. 

Once  the  centers  are  selected  for  each  CSP,  each  winner  informs  the  SR  of 
the  group  id  for  the  interaction  and  the  CSP  id  for  which  it  won.  The  SR  maintains  a 
map  of  the  group  id,  CSP  ids  and  their  associated  centers.  When  all  the  winners  have 
reported  to  the  SR,  the  SR  informs  all  the  CPs  of  the  complete  list  of  center  addresses 
for  the  all  the  CSPs  of  the  group  using  unicast.  Center  selection  is  illustrated  in  the 
example  that  follows. 
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2.  Illustration  of  the  Selection  of  a  Center 

Figure  4.2  shows  a  hypothetical  network  of  12  nodes  with  5  critical  partic¬ 
ipants.  The  CPs  are  indicated  by  filled  squares  and  the  network  routers  are  repre¬ 
sented  by  hollow  circles.  The  link  costs  are  given  alongside  the  edges. 

Assuming  all  the  CPs  form  a  single  CSP,  the  SR  determines  the  selection 
tree  as  given  in  Figure  4.3.  Note  that  none  of  the  routers  in  any  phase  receives  a 
bye  in  more  than  a  single  consecutive  round.  We  expect  that  the  pairing  in  the 
second  phase  onwards  is  not  as  critical  to  the  final  location  as  ensuring  that  there 
axe  no  consecutive  byes.  The  initial  pairing  is  expected  to  place  all  the  second  phase 
pairs  in  the  same  vicinity  if  the  CPs  are  evenly  distributed  in  the  domain.  In  case  of 
non-uniform  clustered  distributions,  this  approach  naturally  makes  the  core  gravitate 
towards  the  heavier  cluster. 

3.  Functions  of  the  SR 

Based  on  the  above  two  aspects  of  the  approach,  the  functions  of  the  SR, 
related  to  the  setup  of  an  interaction,  can  be  listed  2is  follows: 

•  Accept  registration  from  participants  up  to  a  certain  time  before  the  scheduled 
start  of  an  interaction  depending  upon  the  cost  to  the  user.  If  strict  QoS 
guarantees  axe  required  when  the  network  load  is  high,  the  SR  closes  registration 
and  begins  scheduling  earlier  so  that  resources  can  be  blocked  earlier.  Such 
users  caxi  be  charged  more  depending  on  how  long  the  resources  are  reserved. 

•  Determine  the  CSPs  from  the  CPs  based  on  their  reservation  requirements, 
simultaneity  of  sending,  and  the  administrative  domains  in  which  their  locations 
reside.  Assign  a  CSP  id  to  each  CP  and  a  CP  id  within  each  CSP. 
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Figure  4.2;  An  Example  Network 


•  Determine  a  selection  hierarchy  for  pairing  of  CPs  within  each  CSP  and  prop¬ 
agate  it  to  each  member  of  the  CSP. 

•  Receive  the  centers’  addresses  for  each  CSP  at  the  end  of  the  center  selection 
for  each  CSP.  Maintain  a  mapping  of  the  group  id  and  the  CSP  ids  along  with 
the  associated  centers.  Propagate  this  mapping  to  each  CP  of  the  interaction. 

D.  Tree  Construction 

After  the  centers  are  located,  the  tree  establishment  process  and  making  all  the 
CPs,  eis  well  as  the  non-CPs,  aware  of  the  local  core  proceeds  as  follows. 

All  the  CPs  join  all  the  centers  explicitly  for  receive  traffic.  This  joining  can 
proceed  in  a  manner  similar  to  the  CBT  approach  [Ref.  2].  Thus,  a  center-specific 
shortest  path  tree  gets  formed  for  every  center  selected  for  each  CSP.  If  there  is  only 
one  sender  in  a  CSP,  this  tree  will  be  the  same  as  an  SST  for  that  sender. 

Based  on  the  CSP  id  assigned  to  each  CP  by  the  SR  initially,  a  CP  selects 
the  center  address  corresponding  to  this  CSP  id  from  the  list  supplied  by  the  SR 
as  its  home  center.  It  directs  all  the  send  traffic  towards  this  center  along  the  the 
corresponding  CST.  Since  it  is  the  responsibility  of  the  other  CPs  to  join  this  center 
for  receive  traffic,  the  sender  need  not  be  concerned  with  being  able  to  send  to 
the  other  CPs.  All  CPs  that  belong  to  some  other  CSP  id  attach  themselves  to 
this  CST  during  their  join  processing.  It  is  expected  that,  by  having  each  receiver 
join  each  center  separately  for  receive  traffic,  fairly  dissimilar  paths  would  carry  the 
transmissions  originating  at  CPs  in  different  CSPs  to  a  given  end-receiver.  This  will 
alleviate  the  congestion.  Essentially,  by  limiting  an  appropriate  number  of  potentially 
concurrent  senders  to  a  CST,  this  approach  helps  reduce  the  potential  for  congestion 
while  permitting  the  efficiency  resulting  from  the  use  of  shared  trees. 

Dynamic  membership  management  is  similar  to  that  in  the  CBT  approach. 
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Every  router  is  regarded  cis  either  on-tree  or  off-tree  with  respect  to  a  specific  CST. 
An  on-tree  router  knows  which  of  its  outgoing  interface  leads  towards  the  center  of 
the  CST.  Thus,  it  is  likely  that  a  router  is  on-tree  for  one  CST  of  an  interaction,  but 
off-tree  for  another  CST  of  the  same  interaction.  A  router  that  is  on-tree  for  any 
CST  of  an  interaction,  is  called  a  group-aware  router.  Such  a  router  maintains  state 
for  a  group  by  maintaining  a  list  of  all  the  centers  for  the  group-id.  Since  the  number 
of  CSPs  is  expected  to  be  small,  this  state  does  not  represent  a  scalability  problem. 

The  proposed  approach  is  similar  to  PIM  [Ref.  13]  in  that  a  list  of  locations 
is  maintained.  The  important  difference  is  that,  in  PIM  a  list  of  all  the  senders  is 
maintained  at  the  RPs  and  a  new  sender  must  register  with  every  RP.  Clearly,  this 
requires  greater  latency  in  joining  a  group  and  larger  state  to  be  maintained  in  each 
RP  than  the  proposed  approach.  Our  approach  requires  a  new  sender  to  attach  to 
one  of  the  centers  already  known  to  all  the  group-aware  routers.  If  the  new  sender  is 
likely  to  require  its  own  SST  because  it  is  going  to  be  sending  all  the  time,  it  has  one 
of  two  alternatives.  Firstly,  it  can  register  itself  with  the  SR,  become  a  part  of  all  the 
group  aware  routers’  state,  and  acquire  a  tree  with  the  required  QoS.  Alternatively, 
it  can  attach  to  one  of  the  existing  centers  causing  temporary  congestion,  and  get  the 
reservations  on  this  tree  upgraded  eventually.  In  the  second  option,  the  join  latency 
is  less  and  the  state  maintained  by  all  the  routers  does  not  grow  with  the  number 
of  new  senders  requiring  an  SST.  A  new  sender  is  not  guaranteed  of  a  tree  with  the 
required  QoS  anyway. 

However,  this  does  not  address  the  issue  of  changing  the  number  or  locations 
of  the  distribution  centers  once  they  have  been  determined  at  the  start  time.  In  the 
proposed  approach,  no  provision  is  made  for  reconfiguring  the  distribution  centers.  It 
is  assumed  that  the  number  of  unanticipated  senders  of  an  interaction  does  not  change 
excessively  during  the  life  of  an  interaction  that  the  distribution  centers  selected  by 
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the  SR  are  no  longer  applicable.  We  regard  this  as  an  area  for  further  investigation. 

A  new  participant  sends  its  join  request  to  its  directly  connected  router  which 
follows  IGMP  to  propagate  it  to  its  own  directly  connected  routers.  This  presents  the 
possibility  of  burdening  routers  that  have  nothing  to  do  with  a  group  and  are  unlikely 
to  lead  to  any  group-aware  router  by  maJcing  them  propagate  this  join  request.  This 
makes  any  IGMP-based  solution  inherently  non-scalable.  Ideally,  there  should  exist 
a  hierarchical  name  service  for  multicast  group  names  that  any  router  has  access 
to.  It  could  then  query  this  name  service  to  discover  the  group-name  to  list-of- 
centers  mapping  for  the  group  it  wants  to  join.  Such  a  service,  although  envisioned 
[Ref.  19],  does  not  exist  today.  In  any  case,  the  first  group-aware  router  to  receive 
the  join  request  responds  with  a  list  of  the  distribution  centers  for  that  group.  A  new 
receiver  then  joins  every  center  explicitly  and  a  new  sender  selects  a  home  center  and 
joins  the  corresponding  center-specific  tree  explicitly.  This  joining  could  progress  in 
the  same  manner  as  the  CBT  join  processing. 

£.  Reserved  Routing 

The  ability  to  guarantee  a  quality  of  service  depends  on  resource  reservation. 
This  leads  to  two  possible  methods  in  forming  a  multicast  tree.  The  reservations  can 
force  the  tree  or  the  tree  can  force  the  reservations.  In  the  first  case,  a  branch  of 
the  tree  would  not  be  established  unless  sufficient  reservations  can  be  made  along 
that  link.  This  method  compels  an  all  or  nothing  approach.  A  connection  is  only 
created  if  the  quality  of  service  desired  is  attainable  at  that  time.  This  technique 
would  create  a  greater  establishment  delay.  The  other  method  is  to  let  the  routing 
protocol  create  the  multicast  tree  and  then  attempt  to  make  reservations  on  the  links 
already  formed.  The  drawback  here  is  that  the  route  chosen  may  have  insufficient 
reservable  resources  and  hence  may  inhibit  the  desired  quality  of  service. 
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Both  methods  could  allow  a  temporary  degraded  level  of  service  and  then  at¬ 
tempt  to  find  additional  resources.  This  may  be  done  by  acquiring  resources  freed 
up  on  the  existing  branch  or  finding  an  alternate  path  that  provides  a  better  level 
of  service.  Searching  for  the  path  with  the  best  reservation  level  may  be  time  con¬ 
suming,  Therefore  it  is  deemed  better  to  create  the  tree  first  and  then  obtain  the 
resources.  This  may  result  in  a  degraded  service  but  minimizes  establishment  time. 

Since  our  approach  uses  a  priori  information,  the  task  of  acquiring  reserved 
resources  has  the  following  three  phases: 

CST  construction  based  on  resource  availability: 

As  per  the  design  goal  of  integrating  reservations  with  tree  construction,  each 
CST  gets  constructed  based  on  the  resource  availability.  During  the  selection  of 
the  center  location,  the  designated  member  of  a  pair  sends  a  probe  to  the  other 
member.  This  probe  message  is  sent  with  the  type-of-service  (ToS)  option  and 
parameters  set  as  per  the  local  routing  protocol  [Ref.  3].  This  requires  the  probe 
to  seek  the  path  with  the  shortest  path  according  to  the  ToS  parameters.  If  the 
ToS  parameter  used  is  the  unreserved  bandwidth,  the  winner  will  get  located 
along  the  path  that  has  the  most  unused  bandwidth  available.  Use  of  ToS-based 
routing  in  this  stage  will  malce  the  location  selection  mechanism  sensitive  to 
the  current  network  load  distribution. 

Bandwidth  reservation  on  the  CST  formed  for  each  CSP; 

Once  the  center  is  selected,  both  the  senders  as  well  as  receivers  join  each  CST 
explicitly.  The  responsibility  for  establishing  reservations  from  the  senders  to 
the  center  is  borne  by  the  senders  and  between  the  receivers  and  the  center  is 
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borne  by  the  receivers.  This  permits  sharing  of  the  reservation  responsibility 
instead  of  a  purely  receiver-initiated  approach  as  in  [Ref.  6].  With  this  ap¬ 
proach,  the  reservations  made  by  the  senders  are  held  for  the  duration  of  the 
interaction. 

The  senders  acquire  reservation  on  the  CST  as  follows:  each  sender  initiates  a 
count  message  that  is  concast  along  the  CST.  As  the  count  of  this  count  message 
gets  accumulated  upstream  along  the  CST,  each  on- tree  router  initiates  the 
required  reservations  on  its  outgoing  interfaces.  Reservations  on  the  incoming 
interfaces  of  a  router  are  dictated  by  the  sending  end  of  the  interface.  Here, 
we  assume  that  directly  connected  routers  are  able  to  execute  some  low-level 
point-to-point  protocol  that  permits  the  reservations  on  the  incoming  interface 
be  dictated  by  the  sending  end. 

A  receiver  sets  up  a  path  with  reserved  resources  from  the  center  as  follows: 
each  receiver  sends  a  join  message  unicast  to  the  center.  The  first  on-tree 
router  encountered  sends  a  join  acknowledge  (as  in  CBT)  along  the  shortest 
path  based  on  a  ToS-related  parameter,  such  as  the  available  bandwidth  (unlike 
in  CBT).  This  message  establishes  the  maximum  between  the  required  and  the 
available  bandwidth  on  each  interface  it  passes  out  of. 

Acquire  and  release  resources  for  incoming  and  outgoing  participants: 

The  reservations  required  by  participants  that  eurrive  after  the  start  of  the 
interaction  axe  acquired  in  much  the  saxne  manner  as  the  receivers  and  senders 
that  are  CPs.  The  unplanned  senders  reserve  a  path  to  their  home  center 
and  the  unplanned  receivers  reserve  a  path  from  each  center  via  the  join  ack 
resulting  from  their  join  messages. 
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Shortest  paths  computed  based  on  the  ToS-related  parameters  ensure  that  the 
CST  topology  remains  sensitive  to  the  changing  network  load.  It  must,  however, 
be  ensured  that  the  first  multicast  data  packet  traversing  a  new  reserved  path  is 
preceded  by  a  control  packet  that  acquires  the  reservation. 
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V.  Protocols  for  Locating  the  Distribution 

Centers 


Several  protocols  axe  required  to  support  the  multicast  tree  construction  de¬ 
scribed  in  the  previous  chapter.  In  this  chapter,  we  describe  the  protocol  to  locate 
the  distribution  center  for  a  CSP  in  detail  while  qualitatively  describing  the  others. 
First  of  all,  we  list  all  the  protocols  required. 

1.  A  protocol  is  required  for  all  the  potential  critical  participants  to  register  their 
attributes  with  the  special  application  SR.  The  information  exchanged  between 
the  participant  and  the  SR  must  include  an  identification  of  the  interaction, 
the  location  of  the  participant,  its  role  in  the  interaction,  and  other  attributes 
such  as  the  QoS  parameters  desired.  This  protocol  must  also  address  how  the 
participant  will  receive  the  selection  hierarchy  and  the  list  of  centers  once  they 
have  been  selected.  We  call  this  protocol  the  participant  registration  protocol. 

2.  A  protocol  is  required  for  the  registered  participants  in  a  CSP  to  participate 
in  the  pairwise  center  selection  process.  This  protocol  must  address  how  the 
winners  in  a  phase  receive  location  information  about  their  partners.  We  call 
this  the  center  selection  protocol. 

3.  A  protocol  is  required  for  each  sender  CP  to  attach  itself  to  its  home  center 
and  for  each  receiver  CP  to  join  the  CSTs  for  all  centers.  It  must  also  address 
how  the  dynamically  arriving  senders  and  receivers  receive  the  center  list  and 
how  the  senders  choose  their  home  center.  We  call  this  the  tree  construction 
protocol. 
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4.  A  protocol  is  required  to  reserve  the  requirerl  resources  on  the  tree  branches 
for  each  CST.  This  protocol  must  address  how  each  router,  depending  on  its 
location  in  the  tree,  determines  the  bandwidth  to  be  reserved  on  each  outgoing 
interface,  how  directly  connected  routers  negotiate  for  bandwidth  reservation, 
how  the  type-of-service  parameters  are  treated  by  each  router,  and  how  the 
reservation  requirements  are  met  as  resources  become  available.  We  call  this 
the  reservation  protocol. 

While  we  have  qualitatively  described  our  approach  to  the  services  to  be  pro¬ 
vided  by  each  of  these  protocols  in  the  previous  chapter,  we  limit  ourselves  to  the 
detailed  description  of  the  first  two  in  this  thesis.  The  tree  construction  protocol  is 
expected  to  build  upon  the  ideas  presented  for  CBT  [Ref.  2]  ajid  PIM  [Ref.  13].  The 
reservation  protocol  is  expected  to  build  upon  the  ideas  and  approaches  presented  in 
the  literature  on  the  QoS  related  reservation  protocols  summarized  in  Chapter  VII. 

A.  Participant  Registration  Protocol 

This  protocol  supports  an  administrative  mechanism.  As  mentioned  previously, 
we  anticipate  the  existence  of  a  internet-wide  special  application,  called  the  schedul¬ 
ing  register,  similar  to  the  session  directory  tool  [Ref.  17].  Interactions  as  well  as 
participants  along  with  their  QoS  attributes  and  their  role  in  the  interaction  are 
posted  to  the  SR  ahead  of  the  start  time  of  the  interaction. 

The  SR  primarily  deals  with  participants  that  have  planned  their  participation 
in  an  interaiction  prior  to  its  start.  It  does  not  deal  with  participants  that  arrive  after 
the  interaction  has  started.  Registration  for  an  interaction  is  closed  at  a  certain  time 
prior  to  the  start,  as  determined  by  the  network  administration.  Based  on  the  QoS 
requirements  and  other  attributes  for  the  registered  participants  of  an  interaction, 
the  SR  determines  if  a  participant  is  critical  or  not.  Once  all  the  CPs  have  been 
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determined,  it  groups  them  into  subsets,  referred  to  as  critical  set  of  participants 
(CSP),  and  assigns  a  CSP-id  to  it.  This  grouping  occurs  according  to  the  maximum 
number  of  concurrent  senders  permitted  in  a  CSP  for  the  interaction,  the  geographical 
distribution  of  the  CPs,  and  their  reservation  requirements.  The  SR  is  generally  aware 
of  the  internet  topology  and  its  administrative  boundaries  and  is  capable  of  mapping 
host  names  of  the  CPs  to  networks.  This  knowledge  is  used  for  the  grouping  of  CPs 
into  CSPs  each  of  which  spans  a  single  administrative  domain.  The  CSP-id  that  a 
CP  is  grouped  into  is  sent  to  the  CP,  along  with  all  the  other  participants  in  the  CP, 
using  a  unicast.  The  exact  algorithm  used  by  the  SR  for  determining  the  CSPs  is  to 
be  addressed  in  the  future. 

Once  the  CSPs  are  determined,  the  SR  performs  the  task  of  determining  the 
selection  hierarchy  within  each  CSP  for  locating  a  center  for  that  CSP.  As  outlined 
earlier,  the  selection  of  a  center  proceeds  by  a  pairwise  selection  process.  In  order 
that  the  message  exchange  required  to  Ctirry  out  this  selection  is  minimized,  the  SR 
provides  the  complete  selection  hierarchy  as  illustrated  in  the  example  of  the  previous 
chapter. 

The  SR  uses  its  knowledge  of  distances  and  domain  topology  to  form  the  initial 
pairs  of  CPs.  The  initial  pairing  could  be  based  on  the  CPs  that  are  nearby  or 
that  are  far  apart.  Pairing  of  a  CP  with  the  farthest  CP  appears  beneficial  because, 
in  case  the  CPs  are  situated  symmetriciilly,  the  center  may  be  found  very  quickly. 
Also,  pulling  in  CPs  that  are  far  away  from  a  cluster  in  the  initial  phases  will  make 
the  center  gravitate  toward  the  cluster.  The  pairs  in  the  subsequent  phases  are 
determined  according  the  deterministic  algorithm  outlined  in  Fig.  5.1.  It  is  to  be 
noted  that,  due  to  the  initial  placement  of  bye  positions,  the  number  of  successive 
byes  a  winner  gets  in  minimized.  The  algorithm  SR  uses  for  determining  who  gets  a 
bye  in  the  first  phase  is  given  in  Fig.  5.2.  A  bye  position  propagates  in  the  hierarchy 
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Select ionHierarchy  for  CSP  id  =  cspid  at  SR 
numcps  =  number  of  CPs  in  cspid\ 
number  of  phases  n  =  [log,  numcps} ; 

/*slots[i][j]  is  the  jth  winner  in  phase  i;*/ 
initialize  s/ots[0][i]  Vj  €  [1,2”]  with  bye 
using  ByeDetermination; 
initialize  pairs  of  empty  s/ots[0][;]  with  CP  pairs 
in  decreasing  order  of  distance; 
for  i  =  1  to  n 

number  slots  in  phase  i,  numslots  =  2"“’; 
for  j  =  1  to  numslots 

s/of[i][;]  =  winner  of  slot[i  —  l][2ji  —  1]  and  slot[i  —  l][2j]; 
end  Select ionHierarchy. 


Figure  5.1:  Algorithm  for  Determining  the  Selection  Hierarchy 

until  it  meets  a  winner  from  the  previous  phase.  When  a  pair  has  one  bye  position, 
the  winner  from  the  previous  phase  naturally  enters  the  next  phase  as  the  winner. 

Depending  upon  the  cost  of  the  multiparty  interaction  to  the  customer,  the  the 
SR  determines  the  instant  prior  to  the  start  of  the  interaction  for  propagating  the 
selection  hierarchy  to  all  the  CPs  in  a  peirticular  CSP.  This  propagation  is  performed 
using  unicast  messages.  The  use  of  point-to-point  messages  does  not  represent  a 
drawback  since  the  number  of  CPs  is  expected  to  be  small.  Also,  this  occurs  only  at 
the  start  of  the  interaction.  Once  the  CPs  receive  this  pairing,  the  center  selection 
mechanism  gets  triggered. 

B.  Center  Selection  Protocol 


This  is  a  protocol  for  locating  a  set  of  centers,  one  per  CSP,  in  the  network  for 
an  interaction  automatically,  rather  than  administratively.  The  protocol  essentially 
selects  one  out  of  a  pair  of  routers  until  a  single  router  is  selected  as  the  location  of  the 
distribution  center.  For  each  center,  a  shortest  path  tree  based  on  unicast  shortest 
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ByeDetermination  by  SR 

number  of  phases  n  =  [logj  numcps] ; 
byecount  =  2**  —  numcps; 
count  =  0; 
while  byecount  >  0 

m  =  2^^*"**  (fcWMo«n*)J . 

for  i  =  1  to  m; 

set  s/ots[0][2““"^  —  m  +  i]  as  a  bye  position; 
byecount  =  byecount  —  m; 
count  =  count  +  1; 
end  ByeDetermination. 


Figure  5.2:  Determining  the  Bye  Positions  in  the  First  Phase 

path  computed  according  to  the  type-of-service-relaXed  cost  gets  constructed  using 
the  approach  described  in  the  previous  chapter.  If  there  is  only  one  sender  in  the 
CSP,  this  protocol  selects  the  center  at  the  same  location  as  the  sender.  Thus,  it 
yields  a  source-specific  tree.  If  there  are  multiple  senders,  the  center-specific  tree  is 
shared  by  them.  Several  aspects  of  this  selection  protocol  are  described  below. 

We  have  noted  that  the  SR  sends  each  CP  in  a  CSP  the  group  id,  CSP  id, 
id  of  the  CP  within  the  CSP,  the  number  of  CPs  in  the  CSP,  their  locations,  and 
the  complete  selection  hierarchy.  By  the  complete  hierarchy,  we  imply  that  each  CP 
knows  its  partner  in  the  first  phase  and  can  cdso  determine  which  p£urs’  winner  its 
own  winner  will  pair  up  with  in  each  of  the  subsequent  phases.  At  the  end  of  the 
selection  of  winners  for  each  phase,  some  mechanism  must  be  present  so  that  each 
winner  comes  to  know  of  the  location  of  the  other  winner  it  is  to  pair  up  with.  Of 
course,  a  winner  can  determine  if  it  is  the  eventual  winner  for  the  CSP  based  on  the 
number  of  phases  that  have  completed  since  this  number  is  known  deterministically. 

There  Me  two  alternatives  for  determining  the  location  of  the  partner.  Among 
all  the  CPs  that  the  winner  of  a  phase  represents,  one  CP  can  be  designated  as 


42 


the  point  of  contact  (poc)  deterministically,  say,  the  lowest  CP  id  in  that  CSP.  The 
winner  can  send  its  location  information  to  this  poc  from  where  the  other  winner 
collects  it.  Although,  this  enables  the  winners  in  each  phase  go  to  known  locations, 
it  is  not  desirable  since  the  poc  could  fail.  We  choose  the  following  approach. 

The  other  alternative  is  to  ensure  that,  at  the  end  of  a  phase,  every  winner 
knows  all  the  other  winners.  Thus,  every  winner  announces  its  location  to  the  leaxler 
in  each  pair  of  the  previous  phase.  The  leader  of  a  pair  can  be  designated  as  the  CP 
with  lower  CP  id.  Due  to  the  deterministic  selection  hierarchy,  a  CP  can  determine, 
purely  based  on  its  id  and  the  number  of  CPs,  whether  it  is  the  leader  of  a  pair.  It 
sends  a  probe  message  to  its  partner  who  echoes  it.  As  this  message  makes  its  way 
back  to  the  sender,  the  route  gets  recorded.  ^  The  leader  determines  the  winning 
router  for  the  pair  from  the  recorded  route  and  informs  all  leaders  of  the  other  pairs  of 
that  phase  of  its  winner’s  location.  Since  every  leader  performs  the  same  actions,  all 
the  leaders  arrive  at  the  complete  list  of  winners  from  that  phase.  Each  leader  then 
distributes  the  following  items  of  information  to  the  winner  from  its  pair:  the  group 
id,  the  CSP  id,  the  phase  number,  its  id  in  that  phase,  and  the  locations  of  winners 
in  the  phase  completed.  When  the  winner  receives  this  information,  it  determines  its 
partner  and  starts  the  next  phase  by  communicating  with  its  partner. 

The  winner  of  the  final  phase  communicates  with  the  SR  its  selection  as  the 
center  and  the  CSP  id  it  represents.  When  winners  from  all  the  CSPs  communicate 
their  selection  to  the  SR,  it  distributes  the  group  id  and  its  «issociated  list  of  centers 
to  all  the  CPs.  The  center-specific  trees  then  get  constructed  according  to  the  tree 
construction  described  in  the  previous  chapter. 

The  number  of  phases  required  for  center  location  protocol  described  here  to 
select  a  center  is  proportional  to  the  logarithm  of  the  number  of  CPs  in  a  CSP.  This 
^This  is  where  the  assumption  about  the  symmetry  of  the  path  becomes  crucial. 


makes  the  selection  mechanism  fast  and  scalable  in  terms  of  the  number  of  CPs. 
Use  of  the  type-of-service  field  also  makes  this  protocol  sensitive  to  the  current  load 
conditions  in  the  network. 

In  the  next  chapter,  this  approach  is  used  for  selecting  centers  for  large  hypo¬ 
thetical  topologies.  The  results  show  that  the  average  delay  seen  by  the  participants 
using  CSTs  increases  only  marginally  as  compared  to  the  SSTs  (which  yield  the 
lowest  delay)  while  fewer  resources  are  consumed. 
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VI.  Performance  Evaluation 


Three  preformance  parameters  have  been  used,  viz.,  delay,  cost,  and  traffic  con¬ 
centration.  How  appropriate  are  these  given  that  the  future  internetwork  is  most 
likely  to  have  a  rich  topology,  high  bandwidth,  but  with  a  high  probability  of  conges¬ 
tion.  Are  these  parameters  appropriate  when  the  primary  yardsticks  are  how  long  it 
takes  to  establish  a  connection  and  how  many  are  maintained  simultaneously? 

We  mainly  evaluate  the  performance  of  our  core  location  algorithm.  The  algo¬ 
rithm  is  applied  to  a  set  of  random  graphs. 

A.  Generation  of  the  Network  Topology 

A  random  network  is  created  by  the  use  of  Waxman’s  RG2  algorithm  [Ref.  20). 
First  a  maximum  value  for  the  cost  between  any  two  nodes  (L)  and  the  number  of 
nodes  (iV)  is  established.  Next  every  pair  of  nodes  (i,j)  is  assigned  an  integer  cost 
(dij)  utilizing  a  uniform  distribution  from  1  to  L.  The  probability  {pij)  that  a  link 
exists  between  a  node  pair  {i,j)  is  determined  by  pij  =  If  the  link 

exists  then  its  cost  is  dij.  The  parameters, a  and  13,  are  defined  in  the  interval  (0,1]. 
A  small  value  of  a  will  cause  a  relatively  greater  number  of  low  cost  links. 

The  node  degree,  (Ai),  (the  number  of  links  from  a  given  node)  for  node  i  is 
approximated  by 

ff  ^  -di- 

~  X]  Pij  =  X 

Since  dij  is  uniformally  distributed  integers  between  [  I,  T]  there  will  be  approximately 
{N  —  l)/L  of  each  possible  value  of  dij.  This  allows  the  follo.^ing  revision. 

—  2^  exp^z; 
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Letting  exp  =  p  and  observing  that  the  above  equation  is  a  finite  geometric 

sum  of  p  yields 


Ai 


/3(Ar-i)p(i-/) 


L{\-p) 

Since  Aj  can  be  approximated  by  this  method  for  every  i.  the  average  node  degree 
Aoti*  for  the  entire  graph  can  be  approximated  by  this  formula. 

^  _/3(iV-l)p(l-/) 


'^avg 


1(1 -p) 


Solving  for  0  results  in  the  following 

o  ^  Aa,pZ/(l  —  p) 

(.V-l)p(l-pi) 

If  further  simplification  is  desired  p^  can  be  approximated  by  0  and  N  —  \  can  be 
approximated  by  iV  for  L  >>  1  and  N  »  1  respectively. 

This  solution  worked  very  well  but  a  study  on  the  variation  was  not  performed. 
When  average  node  degrees  ranging  from  [3,5]  were  used,  the  graph’s  \avg  was  in 
the  desired  vicinity  but  there  would  still  be  some  nodes  not  connected  to  all  other 
nodes.  These  nodes  were  very  few  in  number  so  the  graphs  were  used  provided  all 
of  the  CP’s  were  connected.  Doing  this  effectively  lowered  by  a  small  amount. 
This  would  not  adversely  affect  results  since  the  results  are  not  specifically  tied  to 
the  number  of  nodes. 

To  build  the  steiner  tree  the  two  closest  participants  were  joined  together  by 
their  shortest  path  link.  Next  the  participant  closest  to  the  connected  participants 
or  any  of  the  nodes  along  the  path  connecting  the  participants  was  added  to  the  tree 
via  its  shortest  path  to  the  nearest  nodeon  the  tree.  This  procedure  was  repeated 
until  all  participants  were  a  part  of  the  tree. 
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B.  Simulation  Results 

Simulations  were  carried  out  to  determine  the  drain  on  network  resources  for 
simultaneous  senders.  For  this,  120  nodes  were  selected  with  the  maximum  cost 
between  connected  nodes  being  8  and  a  was  selected  to  be  0.125  for  all  cases.  Node 
degrees  were  selected  to  be  in  the  vicinity  of  3,  4,  and  5  and  then  3  was  calculated  as 
shown  above  for  each  case.  For  each  node  degree,  a  tree  was  created  that  connected  3, 
9,  and  16  CP’s  together.  The  number  of  simultaneous  senders  was  ranged  from  1  to 
CP  —1.  Since  it  is  not  necessry  for  a  sender  to  receive  himself,  there  is  no  difference 
in  network  resources  utilized  for  CP  —1  or  CP  simultaneous  senders.  The  tree  cost 
for  SST  (Source  Specific  Tree),  CST  (Center  Specific  Tree),  and  ST  (Steiner  Tree) 
were  calculated  for  each  situation. 

Tree  costs  were  calculated  by  determining  the  number  of  sources  that  used  each 
link.  This  was  done  for  both  directions  of  each  link.  Let  be  the  number  of  sources 
that  use  the  link  from  node  i  to  node  j  and  dij  be  the  cost  to  use  that  link.  Let  ss 
be  the  number  of  simultaneous  senders.  The  tree  cost  for  that  link,  is  then  given  by 
tcij  =  min(ss,  Sij)dij.  The  total  tree  cost,  tctot  is  then  tcij-  See  Appendix 

for  the  code  listing. 

Figures  6.1  and  6.2  provide  representative  results.  The  SST  starts  out  with  a 
higher  cost,  peaks  more  rapidly  but  levels  off.  Both  the  CST  and  the  ST  tend  to 
increase  at  a  constant  rate.  When  the  number  of  simultaneous  senders  becomes  large 
it  is  possible  for  the  cost  of  the  CST  to  exceed  that  of  the  SST.  The  shape  of  the  SST 
is  due  to  a  greater  number  of  shared  links  but  these  links  axe  shared  only  among  a 
few  senders.  This  differs  from  the  CST  and  ST  whose  shared  links  are  used  by  most 
senders.  These  figures  show  that  as  far  as  total  network  cost  for  reserved  resources, 
it  is  better  to  use  a  shaxed  tree. 
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Figure  6.1:  Tree  cost  for  A  =  4  and  16  CP’s 
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Figure  6.2:  Tree  cost  for  A  =  3  and  16  CP’s 
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C.  Qualitative  Comparison  With  PIM 


PIM  requires  that  every  receiver  learn  of  each  sender  only  through  an  RP.  This 
implies  that  an  RP,  which  currently  has  no  receivers  that  get  their  multicast  traffic 
through  it,  must  keep  listening  to  every  sender.  In  addition,  a  sender  must  keep 
sending  traffic  to  every  RP,  even  if  each  one  of  them  does  not  have  any  members 
attached.  Let  Ng,Nr  and  Ne  be  the  number  of  senders,  receivers,  and  RPs  (in 
case  of  CSTs  -  number  of  centers)  respectively.  In  PIM,  a  new  receiver  gets  all  its 
multicast  traffic  from  a  single  RP  regardless  of  the  number  of  senders.  In  the  proposed 
approach,  each  receiver  attaches  itself  to  ail  the  centers.  A  sender  sends  its  traffic  to 
only  one  center.  Thus,  PIM  apparently  scales  well  with  the  number  of  receivers  and 
our  approach  scales  well  with  the  number  of  senders.  Since  there  will  typically  be  a 
greater  number  of  receivers  than  senders  it  would  be  better  to  scale  to  senders.  A 
rough  estimate  of  the  size  of  the  solution  for  PIM  is  N,Ne-  This  is  provided  that  all 
receivers  elect  to  receive  their  traffic  through  the  RP.  If  all  receivers  opt  to  gather 
their  traffic  from  every  source,  the  metric  becomes  bounded  by  A^,A,  + AT.Ac,  a  rather 
significant  increase,  ^or  the  proposed  method  it  is  NrNc-  This  does  not  take  in  to 
account  the  efficiency  of  multicast.  For  PIM,  there  is  no  multicast  efficiency  for  the 
first  metric  given.  For  the  second  equation  there  should  be  a  factor  of  improvement 
with  multicast.  For  the  proposal  there  should  also  be  a  similar  factor  of  improvement. 
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VII.  Techniques  to  Guarantee  QoS 


The  following  proposals  lay  the  groundwork  for  the  reservation  protocol  required 
in  this  proposal.  They  all  represent  techniques  to  deliver  performance  bounds  on  real 
time  traffic. 

The  first  two  techniques  examined,  desire  the  network  to  provide  some  of  the 
buffering  enroute  to  the  destination.  This  spreads  the  buffer  requirements  over  the 
entire  path  travelled  by  the  packet  and  alleviates  the  large  buffer  requirement  at  the 
receiver.  As  a  result  these  methods  are  also  non-work  conserving  because  packets 
will  wait  in  the  buffer  until  they  are  released  by  the  protocol,  regardless  if  there  is  no 
other  traffic  being  transmitted.  The  advantage  of  intermediate  buffering  is  it  reduces 
the  overall  buffer  space  required  [Ref.  21],  and  helps  to  eleviate  packet  bunching  and 
hence  congestion  [Ref.  22]. 

The  final  two  approaches  do  not  depend  on  buffering  at  intermediate  nodes  to 
help  reduce  jitter.  As  a  result,  the  receiver  needs  to  provide  all  of  the  necessary 
buffering.  This  is  only  now  becoming  realistic  due  to  the  falling  costs  of  memory 
[Ref.  23].  The  advantages  of  this  method  axe  that  the  routers  do  not  need  to  be 
bothered  with  additional  buffering.  This  will  facilitate  processing  and  thus  keep 
processing  time  at  the  router  minimal.  On  the  otherhand  congestion  dictates  the 
need  to  implement  pre-emptive  buffering  to  prevent  loss  of  real-time  traffic  packets. 

A.  Stop  and  Go  Queueing 

Golestani  proposes  Stop  and  Go  queuing  [Ref.  22,  24,  25,  26].  This  method 
entails  the  use  of  a  time  based  frciming  strategy.  The  source  declares  the  maximum 
bit  rate  r*  over  a  period  T.  A  channel  will  not  be  established  if  the  sum  of  all  r* 


over  ajay  link  exceeds  the  capacity  of  that  link.  The  period,  T,  is  also  involved  in  the 
framing  strategy.  As  the  packets  are  transmitted  from  the  source  they  are  placed  in 
a  time  frame  of  size  T.  At  the  next  node,  none  of  the  packets  in  this  time  frame  are 
eligible  for  transmission  until  the  frame  is  received  in  its  entirety.  Once  the  frame  is 
received,  all  of  the  packets  must  be  transmitted  in  the  next  frame  of  size  T  that  is 
leaving  that  node  on  the  desired  link.  A  disadvantage  of  this  technique  is  that  there 
is  a  requirement  of  initial  synchronization  between  adjacent  nodes.  This  is  needed 
so  that  a  frame  transmitted  is  identical  to  the  frame  received  at  the  next  node.  Also 
the  clocks  at  each  node  need  to  create  each  T  exactly  the  same  size,  otherwise  it  is 
possible  for  packets  starting  out  in  the  same  frame  to  get  split  up  between  frames. 

B.  Tenet  Group 

The  Tenet  group  at  UC  Berkeley  has  put  forth  a  series  of  proposals  [Ref.  27,  28, 
21].  The  latest  is  called  Rate-Controlled  Static-Priority  Queueing.  This  technique 
uses  an  admission  control  and  a  two  part  server.  The  server  consists  of  a  rate  con¬ 
troller  and  a  scheduler.  The  rate  controller  can  be  set  up  to  control  rate-jitter  or 
delay  jitter.  The  rate-jitter  controller  ensures  the  traffic  pattern  for  each  source  at 
any  node  complies  with  the  traffic  characterization  submitted  during  the  admission 
control.  The  delay-jitter  controller  fully  reconstructs  the  traffic  pattern  as  sourced  at 
each  router.  Regardless  of  the  specific  type,  the  rate  controller  assigns  an  eligibility 
time  to  each  packet.  The  packet  is  not  sent  to  the  scheduler  until  after  its  eligibility 
time.  The  Scheduler  consists  of  severed  priority  queues  and  a  non  real-time  packet 
queue.  All  of  the  queues  eire  FCFS.  Each  queue  level  corresponds  to  a  different  delay 
bound,  the  highest  priority  having  the  smallest  delay  bound.  The  server  then  sends 
the  first  packet  from  the  highest  non-empty  priority  queue. 
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C.  Predictive  Service 


Predictive  Service  [Ref.  8,  29]  utilizes  a  playback  point.  In  order  to  calculate 
the  playback  point  requires  knowledge  of  the  bound  on  delay  and  an  estimate  of  the 
percentage  of  packets  missing  this  bound.  Thos  applications  that  require  very  low 
loss  rates  will  use  the  network  computed  maximum  delay  bound.  Other  services  that 
prefer  to  see  less  delay  at  the  expense  of  higher  losses  will  set  the  playback  point 
based  on  the  delay  actually  experienced  on  the  network  plus  some  additonai  time  to 
allow  for  expected  jitter. 

For  traffic  with  rigid  requirements  in  delay  and  reliability  a  scheme  employing 
Weighted  Fair  Queuing  is  proposed.  This  method  is  based  on  the  maximum  bounded 
delay  as  a  result  of  a  flow  receiving  the  same  clock  rate  at  every  switch.  This  will  be 
the  network’s  calculated  delay.  Modeled  on  a  leaky  bucket  scheme  the  bound  on  the 
delay  is  6/r  where  b  is  the  bucket  depth  for  the  flow  and  r  is  the  rate  at  which  the 
bucket  fills  up  and  also  is  the  minimum  bandwidth  required.  This  mehod  has  the 
disadvantage  of  tying  the  bandwidth  requirement  to  the  delay. 

For  traffic  that  can  tolerate  some  loss  due  to  routing  at  the  benefit  of  less 
cost  and  less  delay,  a  mechcinism  called  Predictive  Service  is  presented.  A  key  part 
to  this  service  is  a  queuing  discipline  called  FIFO+.  FIFO+  attempts  to  make 
resource  sharing  fair  over  multiple  hops  and  not  just  for  a  single  hop.  For  this  the 
packets  are  placed  in  the  transmission  queue  according  to  the  time  they  should  have 
received  service.  This  is  determined  by  the  average  delays  according  to  the  packet 
classification.  If  all  packets  in  a  given  class  receive  the  average  service  then  the  queue 
will  appeax  to  simply  be  FIFO. 
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D.  RSVP 


RSVP  (ReSerVation  Protocol)  [Ref.  6]  is  a  protocol  layer  that  utilizes  the  un¬ 
derlying  routing  protocol.  It  is  only  concerned  with  making  bandwidth  reservations 
and  is  not  intimately  involved  in  making  guarantees.  It  would  be  used  by  a  layer  that 
determines  the  necessary  reservation  to  meet  the  quality  of  service  requirements.  It 
utilizes  receiver  initiated  reservationssoas  to  allow  for  heterogenous  receiver  types. 
Also  it  implements  the  use  of  filters.  A  filter  is  set  to  allow  only  a  receiver  specified 
subset  of  senders  to  utilize  the  reserved  resources.  This  permits  the  receiver  to  keep 
the  reserved  resources  but  provides  the  ability  to  change  the  source(s)  received  over 
those  resources. 

RSVP  only  attempts  to  make  reservation  along  a  pre-existing  path.  If  the 
resources  are  not  available  along  the  path  chosen  by  the  routing  protocol,  then  the 
receiver  will  have  to  settle  for  best  effort.  There  is  no  attempt  made  to  have  the 
routing  protocol  find  a  path  along  which  sufficient  reservations  can  be  made. 
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VIII.  Concluding  Remarks 


This  thesis  addressed  the  problem  of  constructing  multicast  trees  with  guar¬ 
anteed  QoS  that  utilize  the  network  resources  efficiently.  It  identified  design  goals 
for  constructing  such  trees  and  presented  an  integrated  approach  to  achieve  an  ef¬ 
ficient  combination  of  CSTs  and  SSTs  based  on  the  a  priori  information  about  the 
participants.  The  specific  contributions  made  are  as  follows: 

•  A  systematic  approach,  based  on  the  critical  participants,  is  described  to  select 
a  combination  of  CSTs  and  SSTs  for  an  interaction. 

•  A  scalable  center  location  mechanism  and  protocol,  that  selects  a  center  trans¬ 
parently  in  a  distributed  fashion  and  balances  the  network  resource  consump¬ 
tion,  is  described. 

•  It  is  shown,  by  simulation  modeling,  that  CSTs  b£ised  on  center  location  as 
above,  provide  almost  the  same  delay  as  SSTs. 

•  It  is  shown,  by  simulation  modeling,  that  CSTs  are  efficient  when  the  number 
of  concurrent  senders  is  small  as  compared  to  the  number  of  participants. 

•  It  is  also  shown  that  CSTs  with  centers  located  as  above  compare  very  well 
with  Steiner  trees. 

A.  Suggestions  for  Future  Research 

The  approach  proposed  in  this  thesis  is  superior  in  many  respects  to  the 
approach  currently  being  considered  by  the  Internet  Engineering  Task  Force  for  stan¬ 
dardization  [Ref.  13].  However,  to  reach  the  same  level  of  maturity  and  to  add  insight 
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to  tree  construction  mechanisms  required  for  wide-area  multicasting  with  minimum 
QoS  in  the  presence  of  a  large  number  of  interactions,  the  following  issues  need  to  be 
addressed. 

•  A  center  selection  mechanism  that  permits  asymmetric  link  costs  needs  to  be 
developed.  This  extension  will  make  this  approach  the  most  general  of  all  the 
approaches  proposed  so  far  in  the  literature. 

•  Selecting  a  hierarchy  of  distribution  centers  will  make  this  approach  scalable 
to  very  large,  widely  distributed  interactions  with  a  large  number  of  senders. 
In  the  near  future,  distributed  interactive  simulation  is  expected  to  require 
such  a  capability.  The  concepts  of  distribution  centers  proposed  here  and  the 
rendezvous  points  proposed  in  PIM  (which  can  be  looked  upon  ais  reception 
centers)  could  be  combined  in  the  most  general  case. 

•  One  question  that  needs  to  be  answered  by  additional  simulations  is;  how 
effective  is  the  proposed  center  location  protocol  in  balancing  the  network  load 
in  the  presence  of  multiple  interactions? 

•  In  the  proposed  approach,  no  provision  is  made  for  reconfiguring  the  distri¬ 
bution  centers.  It  is  assumed  that  the  number  of  unanticipated  senders  of  an 
interaction  does  not  change  so  excessively  during  the  life  of  an  interaction  that 
the  distribution  centers  selected  by  the  SR  are  no  longer  lead  to  efficient  use  of 
network  resources.  This  is  a  difficult  question  to  answer  since  entirely  new  CSTs 
will  have  to  be  created  in  such  a  case.  The  answer  probably  lies  in  selecting 
new  centers  periodically. 

•  Detailed  specifications  of  the  registration  protocol,  the  tree  construction  pro¬ 
tocol,  and  the  reservation  protocol  need  to  be  developed.  In  particular,  the 
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attributes  registered  and  their  use  to  determine  the  (’SPs  of  an  interaction 
need  to  be  categorically  identified. 

•  It  is  expected  that  the  quality  of  the  CSTs  resulting  from  the  proposed  mech¬ 
anism  be  relatively  insensitive  to  the  initial  pairing.  This  needs  to  be  verified 
with  additional  simulations. 
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APPENDIX  A 
PROGRAM  CODE 


X  THESISG&APH.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Th«  graph  ganaratox  portion  of  this  program  is  basad  on  RG2  as  X 

X  dascribad  by  W.  M.  Waxman  in  his  articla  "Ronting  of  Mnltipoint  X 

X  Connactions"  in  IEEE  Journal  on  Salactad  irons  in  Commmications.  X 

X  Dacambax  1988.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boyar  loTaabar  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  xcox  and  ycor  ara  dimansions  for  locating  tha  nodas  X 
X  n  «  nunbar  of  nodas  to  ba  raprasantad  X 
X  alpha  and  bata  ara  paxamatars  of  adga  dascriptions  X 
X  1  (al)  is  tha  max  distanca  batvaan  any  pair  of  nodas.  X 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

global  sp  d  n  hops 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Tha  folloving  command  starts  tha  script  fila  that  asks  tha  nsor  for  X 
X  tha  paxamatars  alpha,  bata,  n,  and  1  and  dataxminas  tha  valuas  of  X 
X  xcor  and  ycor.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


gat.vals 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  Tha  naxt  command  is  a  script  fila  that  dataxminas  tha  oxistanco  X 
X  of  adgas  batvaan  any  two  nodas  and  tha  cost  to  nsa  that  adga.  It  X 
X  ganaratas  tha  matrix  "dCn.n]''  that  is  a  tabla  that  contains  tha  cost  X 
X  batvaan  any  tvo  nodas.  X 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
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•dg«s 


X  Th«  n«zt  conmaiid  is  a  script  fils  that  plots  tha  graph.  Tha  valnas  X 
X  raqairad  for  tha  plot  ara  ganaratad  i&  adgas.a.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


plt.grph 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Tha  naxt  command  is  a  script  fila  that  asks  for  tha  naabar  of  X 

X  critical  participants  and  randomly  locatas  tham  among  tha  nodas.  Tha  X 
X  noda  addrass  of  aach  cp  is  kapt  in  tha  vactor  csp  [cp] .  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


gat.cps 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  Tha  following  command  initializa  4  matricas.  sp  is  tha  distanca  to  X 
X  tha  column  noda  on  tha  shortast  path  traa  soorcad  at  tha  rov  noda,  X 
X  stain  is  tha  distanca  to  tha  column  noda  with  tha  row  noda  baing  tha  X 
X  sonzca  of  tha  stainar  traa.  hops  and  hopstain  axa  :  intarmadiata  X 
X  nodas  batzaan  tha  sonrca  and  dastination  noda  for  sp  and  stain  X 
X  raspactivaly.  X 


hops  =  zoros(n*n  ,  n-2}; 
sp  -  -onesCn,  n); 
hopstain  =  zaros(cp'2  ,  cp-2): 
stain  ~  -onasCcp,  cp); 


X  Tha  naxt  command  is  a  script  fila  that  finds  tha  cora  location  which  X 
X  is  storad  in  tha  variabla  "cora"  as  tha  addrass  of  tha  noda  salactad.  X 


f indcora 


IV 


X  Naxt,  tha  adjacancy  matrix  whara,  tha  only  adgas  ara  tha  branchas  of 
X  tha  traa,  is  mads.  This  snablas  to  datsrmina  tha  distanca  batwsan 
X  CP’s  on  tha  traa. 


a 


X 

X 

X 
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if  sp(cor«,l}  »»  -1 

[spCcoxe,  :),  hops((core-l)*ii+l:cor«*n, : }]  =  shrtpathCcore,  d); 

•nd 

d_cor  »  -bxaaCcora,  csp,  hop8((coxe-l)*n  +  csp,  :),  d); 

[spaxse,  spaLXShop,  xoot]  »  spaxsastCsp.  hops,  csp); 
d.spaxse  -  txe«(xoot,  csp,  spaxshopCcsp,  :),  d); 


X  Tha  naxt  coiomaiid  is  a  scxipt  fila  that  calcnlatas  tha  avaxaga  path 
X  langth  fox  aach  typa  of  txaa  and  tha  cost  fox  aach  typa  of  txaa 
X  dapanding  on  tha  nnmbax  of  simnltanaonsly  txansmitting  sandaxs. 


X 

X 

X 


gan.data 

ont.data 
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t  GET.7ALS.M  X 

ymymm%xx%xxxmmmxmxmymmm%y,i%xxxx%m%%mm%%t%x%%% 

%  This  is  a  script  file  that  obtains  tha  pazaaeters  raqnirsd  for  X 

X  thesisgraph.m  X 

•/.xxxxxxxxy.xxxy.xx%xxx7.xxxxy.xxy.xy.xxxxxxxnxxxxxxxx)ixxxxxxy.xxxxy.xxxxxxxxxxxx 

X  Eric  B.  Boyer  November  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx? 


xxxxxxxxxxxxx 

X  get  alpha  X 

xxxxxxxxxxxxx 


while  1 


end 


Iprintf ( ' \nalpha  is  a  relative  value  (0,1]*) 


f printf ( * \nvhere  a  small 
f printl ( * \nthe  number  of 
f printf ( * \nto  the  number 
alpha  =  input ('Enter  the 
if  alpha  >  0 

if  alpha  <=1 
break 


alpha  will  increase*) 
short  edges  relative*) 
of  long  edges. \u*) 
value  for  alpha:  *); 


end 

end 

f printf  (’ \n\nalpha  needs  to  be  >  0  and  <=  l.\n') 


XXXXXXXXXXXXX 
X  get  beta  X 
XXXXXXXXXXXXX 

while  1 

f printf (* \n\nbeta  is  a  relative  value  (0,1]*) 
f printf (* \nthat  is  proportional  to  the  number*) 
f printf (* \nof  edges. \n*) 

beta  =  input ('Enter  the  value  for  beta:  '); 
if  beta  >  0 

if  beta  <=  1 
break 

end 

end 

f printf (* \n\nbeta  needs  to  be  >  0  and  <=  l.\n*) 
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•nd 

X  gat  n  and  dataxmina  roB  and  col  dimansions  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Bhila  1 

n  =  input C'Entar  tha  numbar  of  nodas:  '); 
if  n  >  0 

if  n  =*  roimd(n) 
braak 

and 

and 

f printf ( ’ \n\nTba  nnmbar  of  nodas  must  ba  a  positiva  intagar.\n*) 

and 

xcoT  =  cail(4*sqrt(n/3)} ; 
ycor  =  cail(3*sqrt(n/3)): 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  gat  maximum  distanca  1  (al)  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Bbila  1 

1  »  input (’Entar  tba  maximum  cost  batBaan  nodas:  ’); 
if  1  >  0 

if  1  ==  round(l) 
bxaak 

and 

and 

f printf ( ’ \n\nTlia  max  cost  naads  to  ba  antarad  as  a  positiva  intagar.Xn'} 

and 
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%  EDGES. M  % 

X  This  script  fils  is  part  of  thesisgxaph.m  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  It  dstexoinss  ths  edgss  and  thsiz  cost  batvesn  nodss  and  generatss  X 
X  information  rsquirsd  for  ths  plot  of  ths  graph.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boysr  Novsmbsr  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  dstsrmins  cost  bstsssn  pairs  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

d»zsros(n,n) : 

for  i*l;n-l 

for  j=i+l:n 

d(itj)  =  csil(l*rand): 

and 

snd 


X  Prspars  for  valnss  nssdsd  to  maks  a  plot.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Ths  nods  ssqusncs  locatss  ths  nodss  on  a  rsctangnlar  grid.  X 

X  xcor  and  ycor  ars  gsnsratsd  and  n  is  obtainsd  in  ths  script  fils  X 
X  gst_vnls.m  X 


coimt6dg=0; 
sdgsx=  □  ; 
sdgs7=  □ ; 
cost=D ; 
coiintn^; 


nods=zsros(n,2) ; 
coordlsf  B  xcorsycor; 
for  j=l:xcor 
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•nd 


for  k=l:ycor 

if  rand  <=  countn  /  coordlof 
nodaCcotmtn.  :)-[j  .k] ; 
coimtn-countii-l ; 

•nd 

coordlcf acoordlcf - 1 ; 
if  n®=0 

br«ak, break 

•nd 


•nd 


X  datargiina  •zistanca  of  edges ,  note  a  valne  of  Inf  means  no  edge  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


for  i=l:n-l 

for  j=i+l;n 

if  rand  >  beta*exp(-d(i, j)/(l*alpba)) 
d(i,j)»Inf : 

else 

conntedgseonntedg+l ; 
costs  [cost :  d(i • j )] ; 

7  s  node(j,2)  -  node(i,2): 
z  s  nodeCj,!}  -  node(i,l); 
edgez  =  [edgez;  node(i,l),  ... 

node(i,l)  +  z/2  +  (abs(y)-l)/(zcor-l) ,  node(j,l)]; 
•dgeys [edgey ;  node (i , 2) ,  ... 

node(i,2)  +  y/2  +  (abs(z)-l)/(ycor-l) ,  node(j,2)]; 

•nd 

d(j,i)  *  d(i,j); 

end 

end 

avg.deg  s  (sxim(sQB(finite(d))}-n}/(n-l); 
f printf ( ’ XnTbe  average  node  degree  is  Xf \n’ ,avg_deg) 
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X  PLT.GRPH.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  script  file  is  pairt  of  thesisgraph.m.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  edgex,  edgey,  cost,  countedg,  and  node  generated  in  the  script  file  X 
X  edges. m.  X 

X  alpha,  beta,  n,  1  are  obtained  in  the  script  file  get_vals.ni.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  code  prints  the  mapping  of  node  connections  and  asks  if  it  is  X 
X  desired  to  have  the  nodes  and  edges  labeled.  The  default  is  n  (no).  X 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  Eric  B.  Boyer  November  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


tog=input('Do  you  desire  the  nodes  labeled  and  edge  costs  printed?  [y,n]:’,*s’) 

hold  off 
clg 

hold  on 
for  i=l;n 

plot (node (i,l) ,node(i,2) , ’so*) 
if  tog  *=  ’y’ 

text(node(i,l),node(i,2),  ['  '  ,set8tr(i'f64)] ) 

end 

end 

for  i-l:countedg 

plot(edgex(i, :},edgey(i, :),'v-') 
if  tog  =*  'y' 

text (edgex ( i , 2) , edgey (i , 2) , int 2str ( cost ( i ) } ) 

end 

end 

title( ['alpha  =  ',  num2str ( alpha) ,  '  beta  =  ',  num2str(beta) ,  ... 

'  max  cost  -  ',  int2str(l),  *  nodes  =  ',  int2str(n)]) 
ylabel(['avg  node  deg  =  ’ ,num2str(avg_deg)3 ) 
axis  off 
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X  GET.CPS.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  script  fils  is  part  of  thssisgraph.m  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  script  fils  asks  for  ths  dssirsd  nimbsr  of  Critical  Participants  X 
X  and  than  randomly  locatss  thsm  among  ths  nodss  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boysr  Novsmbsr  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


vhils  1 

cp  -  input (’Entsr  ths  numbsr  of  Critical  Participants:  '): 
if  cp  >  0 

if  cp  <*  n 

if  cp  ==  round(cp) 
brsak 

snd 

snd 

snd 

fprintf (*\n\nThs  numbsr  of  critical  participants') 
fprintf ('\nmnst  bs  a  positivs  intsgsr  <«  the  numbsr') 
fprintf ('\nof  nodss  vhich  is  Xg.\ii\u'>n) 


/•/•/•/•/•A 


X  locats  ths  CP's  randomly  X 

X  Ths  vsetor  cspCcp]  kssps  ths  nods  addrsss  of  sach  CP 


xxxr 


epeount  -  cp; 
nodslsf  =  n; 
esp  ~  zsrosd.cp); 


for  i  =  l:n 

if  rand  <~  cpcount/nodslsf 
cspCcpcount)  =  i; 
epeount  s  epeount  -  1; 

end 

nodslsf  =  nodslsf  -  1; 

end 
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X  FINOCOBE.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  is  s  script  fils  for  thssisgxaph.m  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  script  fils  sill  locats  ths  cors.  It  usss  ths  Critical  Sst  of  X 

X  Participants  and  finds  ths  optimal  cors  placsmsnt.  It  first  pairs  ths  X 

X  CP's  by  putting  ths  most  distant  CP's  togsthsr.  Each  pair  finds  ths  X 
X  intsxmsdiats  nods  clossst  to  ths  midpoint  bstsssn  thsm.  This  nods  is  X 
X  thsn  pairsd  vith  ths  midpoint  of  anothsr  pair.  This  procsss  is  X 

X  continusd  until  a  singls  nods  is  sslsctsd.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boysr  Novsmbsr  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


for  i 


snd 


l:cp 

a  =  csp(i): 

CspCa.:),  hop8((a-l)«n-*-l  :  a*n,  :)]  =  shrtpath(a,  d); 
if  i  ==  1 

if  sum(sum(isinf (sp(a,csp)))}  >  0 

srrorC'Ths  CPs  ars  not  fully  connsctsd,  try  again.'} 

slss 

fprintf ('\nlts  good!!\n') 

snd 

snd 


xxxxxxxxxxxxxxxxxxxxxxx 

X  DETERMINE  THE  PAIRS  X 

XXXXXXXXXXXXXXXXXXXXXXX 


dcp  =  sp(csp,csp): 
cptally  =  cap: 
pairs  =  □  ; 
cpcount  =  cp; 

vhils  cpcount  >  2 

Da,  indl]  =  max(dcp); 

Dn,  ind2!I  =  max(m); 

pairs  -  [pairs,  cptally(indl(ind2)),  cptally(ind2)] ; 
cptally(Cindl(ind2)  ind2])  =  U; 
dcpC [indl (ind2)  ind2] , : )  =  □  ; 
dcpC : , [indl (ind2)  ind2] )  =  □  ; 
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cpcount  s  cpcoiut  -  2; 

•nd 

pairs  ■  [pairs ,  cptally]  ■, 


mmmmnnmw,mmmmmmmmmmm 

X  This  portion  of  cods  sill  propsrly  locats  the  byss  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  toum  will  hasp  ths  addrassas  of  tha  nodas  involvad  X 
X  and  a  valna  of  -1  is  tha  location  of  a  bya  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

k  a  cail(log2(cp)): 
bya  a  2“k  -  cp; 
countb  a  0; 

tonm  a  zaros(k->-l,2*'k) : 

vhila  bya  >  0 

m  a  2''floor(log2(bya)) : 
for  i  =  l:m 

toiim(l,2“(k-coiintb)-iii+i)  =  -1; 

and 

bya  a  bya  -  m; 
countb  a  countb  1; 

and 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  portion  of  cods  loads  tha  pairs  into  tha  matrix  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  tha  vactor  "pairs"  lists  tha  adrsssas  of  tha  cp's  as  X 
X  thay  ars  pairad,  ths  odd  ona  out  will  ba  at  tha  and  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


countp  a  0; 
for  ial;2:2"k-l 

if  toumCi.i)  'a  -1  %  chack  if  pairad  bya 

if  toumdii+l)  'a  -1  X  chack  if  singla  bya 
for  jal;2 

toum(l,i+j-l)  a  pairs(countp+j) ; 

and 

countp  a  countp  2; 

slsa 
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tonrad.i)  «  paiTs(cp): 


•ad 

•ad 

•ad 

%  This  portioa  of  coda  vill  conqplata  tha  salactioa  % 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxmxxxmxxxxxxxxxxxxxxxnn 


for  phaso  »  l:k 

for  i  =  l:2:2"(k  -  phaso  +1)  -  1 

if  toaraCphaso.i'^l)  ~1  I  toaraCphaso.i'*'!)  toaraCphaso.i) 
tonra(phaso-t-l,(i-*-l)/2)  -  tonra(phaso,i) ; 

•Isa 

toara(plia8a-*-l,(i-fl)/2)  -  fiadcaatCtoaraCphasa.i) ,  ... 
toaraCphasa , i+l } ) ; 

•ad 

•ad 

•ad 


cora  «  toura(k+l,i): 
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t  GEH.DiTA.N  % 

%  This  script  fils  is  for  uss  in  thssisgraph.m  X 

X  This  script  fils  vill  cslcnlsts  ths  avsrsgs  path  Isngth  for  ths  cors  X 
X  bassd  trss,  ths  shortsst  path  (sonrcs  bassd  trss)  and  ths  stsinsr  X 
X  trss.  It  vill  also  calcnlats  trss  costs.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boysr  Novsmbsr  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


cor_pth_lon  =  □ ; 

sp.lsn  *  □ ; 

sparss.lsn  =  □ ; 

cor.hops  3  zsros(cp*n,  n-2): 

spars_hops  »  zsros(cp*n.  n-2): 

for  i  *  l;cp 

Ccorsdist.  cor_hops((i  -  l)*n  *  1  :  i*n,  :)]  =  ... 

shrtpath(csp(i) ,  d_cor): 
cor.pth_lsn  «  Ccor.pth.lsn;  corsdist(csp)] ; 

sp.lsn  a  [sp.lsn;  sp(c8p(i},csp}] ; 

Cspardist,  spars_hops((i  -  l)*n  +  1  ;  i*n,  :)]  =  ... 

shrtpath(csp(i) ,  d_sparss); 
sparss.lsn  -Csparss.lsn;  spardistCcsp)] ; 

snd 

avg_cor_pl  =  siua(cor_pth_lsn’)/(cp-l); 
avg_sh_pl  =  snm(sp_lsn')/(cp-l); 
avg.sprs.pl  =  STimCsparss_lsn*)/(cp-i): 

cor.avg  =  si]ffl(avg_cor_pl)/cp; 
sh_avg  s  svffl(avg_sh_pl}/cp: 
spars.avg  s  snBi(avg_sprs_pl)/cp; 

hops.corin  -  □ ; 
hops.shin  =  □ ; 
hops.sprsin  =  □ ; 

for  i  *  l:cp 

hops.corin  =  Diops.corin;  cor.hopsCCi  -  l)*n  +  csp,  ;)]; 
hops.shin  =  [hops.shin;  hops((c8p(i)  -  l)*n  +  csp,  :)]; 


70 


liops.apxsia  =  [hops .sprain;  apars_hops((i-l)*n  +  cap,  :)]; 

and 

coT_nax  3  max.usaCcsp,  hops.corin) ; 

■hmuT  3  naz.usaCcsp,  hops.shin); 

8pTS_Biaz  *  DAX.uaaCcap,  hops.aprain) ; 

crest  »  □ : 
shest  -  □ ; 
sprscat  3  □ : 

for  i  =  l:cp  -  1 

crest  *  [crest,  tra_cost(cor_maz,  i,  Inf2zoro(d))3 ; 
shest  »  [shest,  tra_co8t(sh_Daz,  i,  Inf2zero(d))] ; 
sprsest  3  [sprsest,  tra_cost(sprs_mBX,  i,  Znf2zaro(d})] ; 

and 
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X  OOT.DATl.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  script  fils  is  for  uss  in  thssisgraph.a  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  file  sill  output  the  data  generated  to  graphs  for  analysis.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boyer  Novenber  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


input ('Which  server  printer  do  you  sant?  [2,3,4,53  : 
printers  C'printl' ,int2str(r)] ; 

xlabelCE'avg  path  len:  CBT  »  ' ,nua2str(cor_avg) , '  SBT  =  ',  ... 

nuffl2str(sh_avg), *  MST  =  *,nu]n2str(spars_avg)3) 
eval(printer) 
hold  off 
clg 

avg_pl  s  Csh_avg,  cor.avg,  spars.avg] ; 

plot(l:3,avg_pl, '•') 

title ('Average  Path  Length’) 

grid 

eval(pr inter) 

clg 

hold  on 

for  i  s  l:cp  -  1 
plot(i,  crcst(i) , 'z' ) 
plot(i,shcst(i) , 'o' ) 
plot(i,sprscst(i) , '+') 
end 
grid 

title ('TREE  COST  vs  #  SINDLTAHEOUS  SEHBEBS') 
xlabel('x  =  CBT,  o  ~  SBT,  -  sparse') 
eval (printer) 
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X  FINDCEMT.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  is  required  by  thesisgraph.n  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  y  -  findcent(a,b)  a  and  b  are  the  nodes  betveen  ebich  the  X 

X  intermediate  node  closest  to  the  center  is  desired.  The  GLOBAL  X 

X  variables  are  the  matrix  of  spCn.n]  shich  gives  the  shortest  path  X 

X  length  between  any  two  nodes;  the  matrix  hops  gives  the  sequence  of  X 

X  nodes  between  those  two  nodes;  n  is  the  total  number  of  nodes;  and  d  X 

X  is  the  adjacency  matrix  fox  all  nodes.  X 

XXXXXXXXXXXXXXXXXXX7.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  Eric  B.  Boyer  November  1993  X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXIXXX 


function  y  -  findcent(a,b) 


global  sp  d  hops  n 
if  sp(a,b)  «  -1 

CspCa,:),  hops((a-l)*n+l  :  a*n.  :)]  -  shrtpath(a,  d); 

end 

midcost  -  sp(a,b)/2; 
rowab  *  (a-l)*n+b; 
count  =  1; 
sumcost  =  0; 


while  sumcost  <  midcost 

if  hops (rowab, count)  ==  0 
Ihop  =  b; 

else 

Ihop  =  hops (rowab, count); 

end 

sumcost  =  sp(a,  Ihop); 
count  =  count  +1; 

end 

count  =  count  -  2; 
if  count  ==  0 


else 

end 


fhop  =  a; 

fhop  =  hops (rowab, count); 


if  sumcost  -  midcost  ==  d(f hop, Ihop) /2 
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y  =  min(fliop.lhop): 

BUfflcost  -  midcost  >  d(fhop,lliop)/2 
y  =  fhop: 

•Ise 

y  =  Ihop; 


end 
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X  Iiil2zaro  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  is  ussd  in  thasisgzaph.m.  Its  pzijnary  use  is  to  change  X 
X  the  Inf  in  a  adjacency  matrix  modified  by  tree.m  to  zeros  so  that  the  X 
X  cost  of  the  tree  can  be  determined.  X 


X  out  s  Inf2zero(in)  vhere  in  is  a  matrix  of  any  size  and  X 

X  out  is  the  same  input  matrix  but  with  any  Inf's  changed  to  0.  X 


X  Eric  B.  Boyer 

•/VVVVVVVVVVVV'i 


November  1993  X 


function  out  =  Inf2zero(in) 

[row,  col]  =  size(in); 

for  i  *  l:row 

for  j  =  l:col 


if  in(i 

,j)  ==  Inf 

outCi.j)  =  0; 

else 

out(i,j)  =  in(i.j); 

end 

end 


end 
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X  L1ST_H0P.M  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  fuaction  is  for  use  in  thssisgraph.a  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  vill  find  the  last  column  of  a  vector  that  does  not  X 
X  contain  a  padded  zero.  X 

X  out  =  last .hop (in.hops)  vhere  in.hops  is  the  input  X 

X  vector  and  out  vill  be  the  column  number.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


X  Eric  B.  Boyer 
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function  out  »  last .hop ( in.hops ) ; 

out  =  length ( in.hops ) : 
while  in.hops(out)  =-  0 
out  *  out  -  1; 
if  out  =»  0 

break 

ezid 


end 


%  iBaz_U8«.m  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  is  fox  us«  in  thssisgzaph.a  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  sill  dstsxmins  the  nuaber  of  sources  that  use  each  hop.  X 
X  cnt_out  =  maz.use (concern,  branch)  share  concern  is  a  X 

X  vector  listiixg  the  nodes  betseen  shich  the  count  is  desired.  It  is  X 
X  assumed  that  the  nodes  in  this  vector  are  the  sources  and  dsstina-  X 
X  tions.  branch[length(concem)''2,n-2]  is  a  matrix  that  lists  the  X 

X  intermediate  hops  betseen  a  node  and  its  destinations.  Note  that  n  is  X 
X  the  number  of  nodes  in  the  original  graph.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boyer  November  1993  X 


function  cnt.out  =  maz.useCconcem,  branch) 


n  =  length  (branch  ( 1, :))  2; 

m  »  length ( concern) : 
cnt.out  =  zeros(n,n): 


for  i 


l:m 

sub.cnt  -  zero8(n,n); 
for  j  =  l:m 

if  i  '=  j 

col  =  last_hop(branch((i-l)*m  +  j,  :)); 
cnt.to  =  concem(j); 
if  col  ==  0 

cnt.fm  =  concem(i) ; 

else 

cnt_fm  =  branch((i-l)*m  +  j.col); 

end 

shile  sub_cnt(cnt.fm,cnt_to)  ==  0 

sub_cnt(cnt_fm,cnt_to)  =  1; 
col  =  col  -  1; 
if  col  ==  -1 
break 


end 

cnt.to  -  cnt.fm; 
if  col  0 

cnt.fm  s  concem(i): 

else 

cnt.fm  s  branch((i-l)*m  j.col); 
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%  SHRTPATH.H  X 

X  This  function  is  lor  use  in  thesisgTaph.in.  X 


X  Csp,  hops]  -  shrtpathCa,  d)  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  shrtpath  input  will  be  soTixca  node  address  (a)  and  the  adjacency  X 

X  matrix  d[n,n].  Output  will  be  sp[n]  shich  is  a  vector  of  distances  X 

X  from  the  source  to  all  other  nodes  and  hops[n,n-2]  which  is  the  X 

X  intermediate  nodes  between  the  source  and  the  destination.  Note  that  X 

X  hops  is  padded  with  zeros  to  make  all  row  vectors  have  a  length  X 

X  of  n-2.  X 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
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function  [sp.  hops]  =  shrtpathCa.  d) 

n  s  sizeCd.l); 

8psInf*ones(l,n) ; 
parent  =  a*ones(l,n): 
hops  *  [] ; 

sp(a)  =  0; 
ntcG.ly  =  l:n: 

while  lengthCntally)  >  1 

[m.i]  =  minCspCntally}) ; 
checkwho  =  ntallyCi); 
ntally(i)  =  □ ; 
dsp  =  dCcheckwho.ntally) ; 
for  i  =  1 : length(ntally) 

if  m  dspCi)  <  spCntallyCi)) 

spCntallyCi})  =  m  dsp(i); 
parentCntallyCi))  =  checkwho; 

end 

end 

end 

lor  j  =  l:n 

hopping  -  parent (j): 
while  hoppingCl)  a 

hopping  -  [parentChoppingCl)) ,  hopping]; 
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•nd 

hoppiagd)  »  □  ; 

hopping  -  Chopping.  zorosCl.  n-: 

hops  »  [hops :  hopping] ; 

end 


lengthChopping}}] ; 
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X  SPl&SEST.N  X 

yxmmyxmixmmxmxy.xy.m%%y,mmyimmmyMxtxmy,m%mmn 

X  This  limction  is  for  ass  in  thssisgraph.m  X 

xxxxxxxxxxxxxnxxxxxxxiixxxxxxxxxxxxxxxxmxxxxiixxx^mxxmmxxxxm^tnx 

X  [spsxss,  spaxshop,  root]  »  sparssstCsp,  liops,  csp)  X 

X  vhsrs  sp  is  ths  shortest  distance  between  all  nodes  of  graph,  hops  is  X 
X  the  intermediate  hops  betveen  any  teo  nodes  of  the  graph,  and  csp  is  X 
X  a  vector  that  contains  the  nodes  that  need  to  be  connected  by  the  X 
X  sparse  steiner  tree.  The  output  sparse,  is  the  shortest  distance  from  X 
X  the  node  in  csp  selected  as  root  and  all  other  nodes.  If  the  X 

X  destination  node  is  not  on  the  sparse  tree,  then  that  value  trill  be  X 
X  Inf;  root  is  the  node  in  csp  selected  as  the  root  of  the  tree.  X 

X  Eric  B.  Boyer  November  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


function  [sparse,  sparshop,  root]  -  sparsestCsp,  hops,  csp) 

n  -  size(sp,l): 
sparse  -  Inf«ones(l,n): 
sparshop  -  zerosCn,  n-2): 
dstein  «  sp(csp,csp): 
cp  =  length(csp); 

for  i  =  l:cp 

dstein(i,i)  -  Inf; 

end 

[m,i]  =  min(dstein); 

Cm,j]  =  min(m); 
root  =  cspCiCj}); 

col  =  last_hop(hops((root-l}*ntcsp(j}, :}); 
ntally  s  csp; 
ntally([i(j)  j])  =  □; 

mtally  *  [root,  hops((root-l)*ntcsp(j),l:col),  csp(j)]; 
sparshopCcspCj), :)  -  hops((root-l)*ntcsp(j),:); 
sparseCcspCj})  =  sp(root,csp(j)) ; 
for  h  =  l:col 

if  k  '=  1 

spar shopC sparshopCcspCj),  k),l:k-l)  =  sparshopCcspCj),  l:k-l); 

end 

sparseCsparshopCcspCj) ,  k))  =  spCroot,  sparshopCcspCj),  k)); 
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•nd 

while  length (ntally)  >  1 

dstein  =  spCntally,  mtally); 

Cm.i]  =  min(dBtein): 

Dn.j]  *  Biin(a); 
if  mtally(j)  '=  root 

coll  s  last.hopCsparshopCatallyCj) ,  :)); 

parti  =  [spar shop (mtally(j).  l:coll),  mtally(j)]; 

else 

parti  =  □  ; 

and 

coll  =  length(partl) ; 

col2  *  last_hop(hops((ntally(i(j))  -  l)*n  +  nitally(j),  :)); 
part2  *  fliplr(hops((ntally(i(j))  -  l)*n  +  mtally(j),  l:col2)); 
if  parti  □  I  part2  '=  □ 

sparshop(ntally(i(j}}.  l:(coll  col2))  =  ... 

[parti,  part2] ; 

end 

sparsa(ntally(i(j))}  s  sparseCntallyCj))  +  ... 

sp(ntally(i(j)).  ntallyCj)); 
for  z  =  l:col2 

if  coll  0  I  X  >  2 

sparshopC  part2(z)  ,  l:coll+z-l  )  -  ... 

sparshopCntally (i( j ) ) ,  1 ; coll+x-1) ; 

end 

sparse (part2(x))  -  sparseCntallyCKj)))  -  ... 
8p(ntally(i(j)},part2(x)); 

end 

mtally  -  [mtally,  part2,  ntally(i(j)}] ; 
ntally(i(j))  =  □; 

end 

dstein  s  spCntally, mtally) ; 

[m,j]  =  min(dstain); 
if  mtally(j)  '=  root 

coll  =  last_hop(spar8hop(mtally(j),:)); 

parti  3  [sparshopCmtallyCj) ,l:coll) ,  mtally(j)]; 

else 

parti  =  □ ; 

end 

coll  3  length (parti); 

col2  3  last _hop(hops((ntally-l)*n+mtally(j ),:)); 
part2  3  fliplr(hops((ntally-l)*n+mtally(j),l:col2)); 
if  parti  '=  □  I  part2  □ 

sparshopCntally,!: (coll  +  col2))  3  [parti,  part2] ; 
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•nd 

spars* (ntally)  ■  spars* (mtally(j))  +  spCntally.mtallyCj)); 
for  X  s  l:col2 

if  coll  "=  0  I  X  >  2 

sparshop(part2(x) .  l:(coll+x-l))  =  sparshop(xitally.  . 
1: (coll+x-1)) ; 

*nd 

spars* (part2(x))  =  spars* (ntally)  -  spCntally,  part2(x)); 

*nd 
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%  This  limction  is  for  nss  vith  thssisgraph.ai  X 

%  This  function  will  dstsmins  ths  cost  of  a  traa  givan  a  matrix  of  the  X 
X  nufflbar  of  timas  a  traa  usas  a  hop  batwaan  two  nodas.  This  matrix  can  X 
X  ba  ganaratad  by  tha  function  max.usa.  Tha  function  also  raquiras  tha  X 
X  numbar  of  simnltanaously  transmitting  sourcas,  and  finally  an  X 

X  adjacancy  matrix  that  indicatas  tha  cost  batwaan  nodas.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  out  »  traa_cost(maxmat,  val,  d)  whara  maxmat  is  X 

X  tha  matrix  indicating  tha  numbar  of  timas  a  hop  is  usad;  val  is  ths  X 
X  numbar  of  simnltanaously  transmitting  sandars;  and  d  is  tha  adjacancy  X 
X  matrix  with  tha  cost  of  adjacant  hops.  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  Eric  B.  Boyar  Hovambar  1993  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


function  out  »  tra.cost (maxmat,  val,  d) 

most  =  val*onas(siza(maxmat)): 
laast  >  minCmost,  maxmat); 
out  -  sum(sum(laast  .*  d)); 
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%  TKEE.M  y, 

X  This  function  is  for  us«  in  thesisgraph.m  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  This  function  will  dstezmina  th«  adjacancy  matrix  for  a  givan  traa. 

X  d.traa  »  traa(src,  concam,  branch[(langth(concam)  ,n-2] ,  d) 

X  vhara  src  =  noda  id  of  tha  root,  concam  -  vactor  of  noda  ids  to 
X  which  tha  traa  is  to  ba  mada,  branch  is  tha  intarmadiata  nodas 
X  batwaan  tha  root  and  tha  nodas  listad  in  concam.  d  is  tha  adjacancy 
X  matrix  of  tha  original  graph. 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXy^^^^*'’'''^'''' 
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function  d_traa  =  traaCsrc,  concam.  branch,  d) 

n  =  langth(branch(l. :))  2; 

d_traa  -  Inf «onas(n.n) ; 
for  i  •  l:n 

d_traa(i.i)  =  0; 

and 

for  i  -  l:langth( concam) 

if  concam(i)  '=  src 

col  -  last_hop(branch(i.  :)); 
d.to  -  concam(i); 
if  col  ==  0; 

d_fm  =  src; 

alsa 

d_fm  =  branch(i,col) ; 

and 

vhila  d_traa(d_fm,d_to)  ==  Inf 

d_traa(d_fm.d_to)  =  d(d_fm.d_to) ; 
d_traa(d_to.d_fm)  =  d(d_to.d_fm) ; 
col  =  col  -  1; 
if  col  ==  -1 
braak 

and 

d„to  =  d_fm; 
if  col  ==  0; 

d_fm  =  src; 

alsa 

d_fm  =  branch(i.col) ; 
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